On 9/14/2026 4:58 PM, Fabiano Rosas wrote: > Hi, I just wanted to share and ask for feedback on some container images > I've been building as part of my testing of migration pull-requests. > > From a Dockerfile from ./tests/docker/dockerfiles/ I'm producing the > following: > > $ docker images > qemu-build-base:11.0.0 b6efa198e93a 5.8GB > qemu-rootfs-base:11.0.0 72bcb5418f4d 4.08GB > qemu:11.0.0 018a3f0f4dcc 2GB > > This last image is stripped (for size) of everything but a few libs and > binaries (qemu, gdb, migration-test, sh) and has an entrypoint of: > > CMD ["qemu-system-x86_64"] > > The point is that I can wrap it in a script called qemu-system-x86_64 > and run it interchangeably with any other qemu binary during > migration-test: > > QTEST_QEMU_BINARY_SRC=./build-11.0.0/qemu-system-x86_64 \ > QTEST_QEMU_BINARY=./build-master/qemu-system-x86_64 \ > ./tests/qtest/migration-test > > (note that migration-test spawns the qemu binaries itself) > > I run tests against the previous 3 QEMU releases. At every release I > build the container for the new release and at every PR I build the > container for that git hash using the latest tag as a base. > > The reasons that lead me to this solution are: > > 1) Migration compat testing is special, the two migration peers can run > in different OS versions, so their QEMU builds can be quite different. I > cannot test using *just* my dev machine, neither using *just* a > container. I need two hosts. Or two containers running different OSes > that can both be reachable by the migration-test binary running in > either of the OSes. > > 2) Neither the QEMU build nor the distro repos are reliable enough to > allow me to just "go back in time" and rebuild at any moment, I need to > keep the artifacts cached to avoid rebuilding. Otherwise it comes time > to send a PR and I discover that some python piece has changed or the > distro messed up the older repository. > > Any thoughts on this? Could it be useful to anyone? Maybe the stable > branch has some similar issues? >
That's a good approach. If you want to go further, you could directly host it on dockerhub, for debian or fedora hosts, so other don't need to rebuild anything. And everytime there is a new release, we would just add the new image. $ ./scripts/qemu-time-machine.sh qemu-system-aarch64 11.1.2 "$@" podman run -it --rm \ -w $(pwd) -v $(pwd):$(pwd) \ docker.io/qemu-releases/qemu-system-aarch64:11.1.2 \ /usr/bin/qemu-system-aarch64 "$@" You can drastically optimize size by using multi-stage builds. All images can be based on a common deps image, which contain all libraries qemu depend on (~140MB from what I can see on my debian system), and then all qemu-* images would be FROM:deps, and they only add a single binary inside. Final result would be 140MB for base deps + binary size per image on top, (from 3MB to 40MB) per binary. And we could have the whole collection of qemu binaries available for everyone with a single script. Regards, Pierrick
