Frequently asked questions

Why is vmtest so slow on my machine?

vmtest relies on hardware acceleration for performance. It will, however, fall back to emulation if hardware acceleration is not available. If vmtest is running your code abnormally slow, then check if your host supports KVM. One easy way to check is by seeing if /dev/kvm exists.

Why is vmtest slow in Github Actions?

vmtest relies on hardware acceleration for performance. Standard Github Action runners do not support nested virtualization. Meaning that vmtest cannot take advantage of hardware acceleration (see above "Why is vmtest so slow on my machine?").

The good news is that Github now supports nested virtualization on large runners. Unfortunately large runners are currently only available for paid plans, so most open source projects will not be able to take advantage of nested virtualization.

Another option is to self host a bare metal runner. This usually sounds quite appealing (install a server in your closet) but has significant security downsides. There are companies working on this problem, though.

How do I run docker inside vmtest?

Docker is quite tricky to run inside vmtest b/c it requires a lot of mutable host state as well as communication over a unix domain socket to the dockerd daemon. Unix domain sockets cannot be shared across host and guest VM. dockerd does, however, support TCP sockets. But that is tricky as well b/c now you need to bring up networking inside the guest VM.

Ultimately, I don't think it's worth the trouble to set up docker inside the guest. Rather, prefer to run vmtest inside the docker container. This workflow is supported and works quite well.

How do I run podman inside vmtest?

In contrast to docker, podman is daemonless, meaning it should avoid the issues that docker has with vmtest, right? Kind of.

Podman still suffers from relying on mutable host state. This can be worked around by adding rw to the kernel command line to make the rootfs mutable.

Podman by default (at time of writing) also relies on overlayfs to achieve rootless container execution. B/c of how vmtest is designed, all kernel modules need to be built into bzImage for vmtest guests to use them. While in theory it is possible to track down all the configs podman requires, I didn't go down that rabbit hole far enough.

Instead, prefer to run vmtest inside the podman container, just like with docker.

Is there a way to prevent the guest VM from modifying my host state?

By default vmtest mounts the directly rooted by vmtest.toml (or the current directory if using the one-liner interface) readable and writable at /mnt/vmtest. There is currently no way to opt out of this.

Furthermore, vmtest kernel targets will map the host userspace into the guest as its rootfs readable and writable. If you do not want the host userspace to be R/W, supply a ro kernel argument.