On 10/8/26 5:48 PM, Pierrick Bouvier wrote:
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.
I gave a try to this, see:
https://lore.kernel.org/qemu-devel/[email protected]/T/#t
Regards,
Pierrick
