Fabiano Rosas <[email protected]> writes: > Peter Xu <[email protected]> writes: > >> On Mon, Sep 14, 2026 at 08:58:09PM -0300, 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. >> >> I'm not a container person, > > Me neither, lol. Last container work I did was back when multiarch > manifests were being added to docker. Maybe 2016? I (clearly) haven't > kept up with the progress in the area. > >> e.g. I did test my recent channel fix on >> qemu-7.2 by simply building it with build-7.2/.. but after learning it the >> idea using a link to kickoff the container is very interesting on its own >> already. >> > > Yeah, the issue is that `git checkout <old version>` and try to build it > is pretty hit or miss. > >>> >>> 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. >> >> True.. One thing I want to make us on the same page is, this is about >> distro, not OS? Say, the kernel is still the same. >> > > Yes, it's about what it takes to get a working QEMU binary. I'm not > trying to cover a realistic migration scenario, I'm simply trying to > test across QEMU versions *somehow*.
You could just consider using the system qemu if installed and then we get the variance between versions from which OS's we build on. That would work outside the container and we could include qemu-system in the containers as well. It would cover the migrations from the various LTS qemu's to current master which should be the majority of common use cases. -- Alex Bennée Virtualisation Tech Lead @ Linaro
