cloud-hypervisor VS init-snapshot

There is no mention of cloud-hypervisor[1] (also in the rust-vmm ecosystem) in the article. It has the memory reclamation feature they require. It also support VFIO and virtiofs.

[1] <https://github.com/cloud-hypervisor/cloud-hypervisor>

https://github.com/tandasat/Hypervisor-101-in-Rust is there to help

https://github.com/cloud-hypervisor/cloud-hypervisor isn't educational necessarily but is one of the most technically progressive fastest developing highest funded vm projects ever, and there are oodles of tech talks on it. I am not qualified to make any specific recommendations, but there's tons of stuff here.

> The goal of the Cloud Hypervisor project differs from the aforementioned projects in that it aims to be a general purpose VMM for Cloud Workloads and not limited to container/serverless or client workloads.

Firecracker is such a great piece of technology. I'm amazed that AWS actually open-sourced it. All kudos to them. We're using Firecracker at our company to allow API companies build interactive demos like this one we built for Prisma [1].

[0] https://github.com/cloud-hypervisor/cloud-hypervisor

[1] https://playground.prisma.io

Relatively new project 'Cloud Hypervisor' https://github.com/cloud-hypervisor/cloud-hypervisor seems to launch images faster.

The Chrome OS hypervisor was then evolved/forked into Firecracker and Intel's Cloud Hypervisor, with the latter supporting both Linux and Windows. Perhaps Cloud Hypervisor would serve as a good backbone for sandboxing, with its Rust implementation and focus on security?

GitHub - cloud-hypervisor/cloud-hypervisor: A Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.

Did you guys think about live migrations? https://github.com/cloud-hypervisor/cloud-hypervisor seems to support it and it shares a good amount of code with firecracker.

Virtink is a Kubernetes add-on for running Cloud Hypervisor virtual machines. By using Cloud Hypervisor as the underlying hypervisor, Virtink enables a lightweight and secure way to run fully virtualized workloads in a canonical Kubernetes cluster.

At CodeSandbox we use Firecracker to run our VMs (more info here: https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s...).

To answer the questions:

> what version of the kernel do you use (the github page says 5.10 but isn't that quite old?)

Right, they have tested with 5.10, but it also works with higher kernel versions. Our host currently runs 5.19 and we're planning to upgrade to 6.1 soon. The guest runs 5.15.63, we use a config very similar to the recommended config by FC team (it's in the FC repo). It's important to mention that we had to disable async pagefaulting (a KVM feature) with more modern kernel versions, as VMs could get stuck waiting for an PF resolve.

> What do you use to build the 'micro' images

We created a CLI that creates a rootfs from a Docker image. It pulls the image, creates a container and then extracts the fs from it to an ext4 disk. For the init, we forked the open sourced init from the Fly team (https://github.com/superfly/init-snapshot) and changed/added some functionality.

> How do you keep timesync of you're not using a timesync daemon?

IIRC we expose the time as a PTP device (handled by kvm) and run phc2sys to sync the time in an interval. Firecracker has some documentation on this, where it recommends chrony. It can also be done with vsock, but it would be more manual.

> Handle kernel and app logs without adding an log daemon, and same through vsocks, etc?

The init forwards stdout/stderr of the command it runs to its own stdout, which Firecracker then logs out by itself. A supervisor reads these and writes the logs to files.

Unless they’ve changed things, there is no containerization within the VM a la kata. They run their own custom init inside the VM and use it to start the entry point. https://github.com/superfly/init-snapshot is the source.

Jerome wrote our init in Rust, and, after being cajoled by Josh Triplett, [we released the code (https://github.com/superfly/init-snapshot), which you can go read.

> Fly.io transforms container images into fleets of micro-VMs running around the world on our hardware.

Oh boy!

> None of us have ever worked for Google, let alone as SREs. So we’re going out on a limb

Oh.... boy.

> We spent some time scaling it with Thanos, and Thanos was a lot, as far as ops hassle goes.

You know, they have these companies now, that will collect your metrics for you, so that you don't have to deal with ops hassle.

Holy shit. I see they even wrote their own init... in Rust. Yes, the thing that is normally a shell script, is now a compiled program in a new language, that mostly just runs mkdir(), mount() and ethtool(). (https://github.com/superfly/init-snapshot/blob/public/src/bi...)