In the cloud computing tutorial we are starting VMs with QEMU dynamically, but I am relying on the DHCP server in my router to assign IP addresses. This is a problem because every time I want to SSH into a server, I have to lookup the current IP lease for the VM on my router’s web interface. In this part of the tutorial series we will look at possible solutions to retrieve the guest IP address of a QEMU VM and implement one of them.

In this tutorial we will setup correct message passing in RabbitMQ for our cloud computing provider. If you think back to the first tutorial, you might remember that we had the problem that list-vms commands were only sent to one server - just like all other messages. Moreover, what use is it if server A gets the create VM command, but server B gets the delete VM command for the same VM? Our users would get erroneous replies that the VM does not exist. As you can see there is quite some mess to clean up.

It’s already been quite some time since I have written about MQTT and ZeroMQ. Let’s continue the overview over messaging systems with a look into RabbitMQ now. I am currently using RabbitMQ for my tutorial series on the development of a simple cloud computing platform.

In this tutorial I want to show how you can trigger a clean shutdown of your QEMU guest VM from Python. This is not as simple as one might expect, but also not so difficult. If you only stop the QEMU process, it will be a reset inside the guest VM. For a clean shutdown of a QEMU guest we have to use the QEMU monitor and send a shutdown command there.

If you’re running QEMU instances without libvirt, you have the problem that there is no daemon managing your instances. If your host reboots, the VMs will not be re-created. In this part of my cloud computing tutorial I will use systemd to create QEMU VMs that are managed by a daemon (in this case systemd). If you haven’t followed along my tutorial series, you can just read the systemd info and skip the Python parts.