qemu-micro-env was created to make it easy to test various projects against different kernel features. For instance container runtimes need to be able to test against both cgroups v1 and cgroups v2, which can be cumbersome to get running. Its especially useful for fast a fast dev/test against these kernel features (e.g. after build caches are warmed a new VM should be ready in a couple of seconds).
qemu-micro-env utilizes buildkit to:
qemu-micro-env then executes a normal container in Docker with the built image and executes the VM in that container with qemu. The exected VM, by default, is run as the same UID/GID as the user executing qemu-micro-env. It is expected that docker is running locally to the client since it expects to get a docker.sock from the container (which is forwarded from the VM).
The executed VM runs a simple init process that:
The original goal of the project was to get dockerd running in the VM in a way that is accessible outside the VM as quickly as possible. While many parts of the project do try to let users do whatever they want, there are some assumptions made about the original use case currently and may not work as expected right now.
All the commands below elide the --debug
flag, which is currently the only way to see what's being built.
Set that flag to see what's happening. This also adds some extra output during the kernel boot phase.
In the future this may be opened up to support custom buildkit daemons, but for now it will only connect to the buildkit instance provided by dockerd.
$ go install github.com/cpuguy83/qemu-micro-env@latest
$ qemu-micro-env
With the above you will get a VM running with dockerd running in it. The first execution may take a few minutes because it needs to build everything, subsequent runs should execute in a few seconds.
You can split the build and run phase as well:
$ qemu-micro-env build | qemu-micro-env run
The build
subcommand outputs a container image digest which the run
subcommand will read either from stdin or from the first argument to the command.
You can also tag an image with -t
and then run it with docker run
.
docker buildx build
(as an example) but right now it is not, and is only visible with --debug
enabled.