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.

If you’ve followed the first part of this series, you’ll remember that our server script currently requires root privileges to setup a TAP device for each QEMU instance. It would be much nicer if this was not needed and instead our script could run in user-mode. This is possible with VDE networking.