• VDE Networking for our Cloud Computing

    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.

  • Using flask-log-request-id in Backend Workers without an HTTP Request

    flask-log-request-id is a small extension for Flask to forward a request ID from HTTP requests to logging. By default, it works with X-Request-ID, X-Correlation-ID, and AWS’s X-Amzn-Trace-Id. I recently wanted to propagate the request ID to a worker that does not use HTTP and thus does not receive any of the above headers.

  • Let's Program our own Cloud Computing Provider with Python, RabbitMQ and QEMU

    In this tutorial I show how we can create a very simple scalable cloud computing provider for fun. It will allow us to start VMs from base images by sending messages to a message broker. All of this will be based on QEMU to run VMs, RabbitMQ to handle messaging and Python for the code.

  • Transparently Connecting QEMU VMs from Multiple Hosts with a VPN

    On cloud hosting it is usually possible to connect machines with a VPN, so that it looks as if all of them were in a real physical subnet. At Amazon and Google this is called Virtual Private Cloud (VPC) and Microsoft calls it Virtual Network (VNet). Google also tells us that in their case it is implemented using Andromeda. I’m currently trying to perform these actions on a VM playground. The idea is to do a fun hobby project and to learn more about networking and Linux tooling.

  • Hosting QEMU VMs with Public IP Addresses using TAP Interfaces

    Recently, I wanted to play around a bit with hosting services in VMs. Let’s imagine we want to host a service for a customer, but the service is so simple that a physical server would be overkill. Still, the server should look like a physical server to the user. For a VM to be transparent to the user, it needs to have a public IP address and should be exposed to the public internet like a real server would. If our VM would use the IP address of the host machine, we could only serve each port once and thus multiple customers would not be able to host services on the same port at the same time (except it is handled on the host in another way, e.g. by DNS name). This is of course unsatisfactory.