On 10/23/2026 8:33 AM, Fabiano Rosas wrote: > Pierrick Bouvier <[email protected]> writes: > >> This series was inspired by a recent post from Fabiano to provide container >> images for migration tests: >> https://lore.kernel.org/qemu-devel/[email protected]/T/#m353f119dc1a24fa437dde8a96d1891629e64303c >> >> The idea to be able to build and run any QEMU (past) release with containers >> was >> in my mind for some time, so I gave it a shot. Finally, it was easier than >> expected to obtain a single dockerfile (with a few hacks) that works over all >> our releases. >> > > Good stuff, thanks for this work. I'm just not sure how much of it fits > upstream in the current shape, let's discuss... > > You say this was in your mind for a while, could you elaborate a bit on > how you think this could benefit the project? >
First usage that comes to my mind is that it would greatly help for migration, allowing automatic testing in CI, by just downloading any previous QEMU, dump a machine, and restore it on current version. We could do it for last 10 releases to ensure migration from packaged versions in all supported distros (red hat, alpine, ubuntu, ...) work as expected. It could be a enhancement compared to the manual process done once per release. I read many times in review "it breaks the migration", that yes, it would be nice to have CI saying "this series broke the migration from qemu x.y". Beyond that, I think we could also offer a "rebase on steroids" tool. We could extend list of containers published to all top merge commits (git log --first-parent), and provide a fast rebase, based on download only. See it as a giant immutable precompiled cache. Dockerhub storage is free and unlimited. Some quick math: Since 8.0, there are ~2000 top merge commits. Each image is < 250MB compressed, so the whole thing would be < 500GB. Finally, in my personal case, while working on single binary, I had to compare output of qemu help between versions. I'm also interested to track QEMU binary size evolution over time. And some personal fun with software archeology on the project too for anyone. > To be clear, my use-case is simply to produce a few containers for > testing migration on my workstation. Your series can help a lot with > that, but from my point of view, some parts are clearly extra and some > are missing. > > Also beware that what you're touching here is both "infrastructure" and > "publishing". This has implications for how people consume the work of > the project. There's a chance that people see this as "official QEMU > containers" and try to use them in all sorts of weird scenarios that we > as a community are not prepared to maintain. You might get some > push-back on that basis. > Sure, it was free to generate all images and push them on my personal dockerhub, and it's now automated to push any feature release also in a GitHub nightly job. If we want to make it more official, it should really be hosted on an official account. >> The oldest functional distro we can find nowadays is ubuntu 12.04. Because of >> this, the oldest QEMU release we can build is v0.12.0. Previous ones require >> an >> environment we can't get easily today. >> > > I think the ability to go all the way back is very cool, but unless we > want to look at this from a archival or heritage perspective, I'd say > there's a line somewhere to how old we should go. I don't see an > use-case for very old binaries. Even knowing if they still work would > already incur in a maintenance cost. > Agree, mostly was a fun challenge. I was also curious to see until when we can go back in past from 2026. For the "maintenance" a scheduled CI job running nightly is a free thing for me, but I understand opinions on "maintenance cost" may differ. I also co-maintain tests/docker with Alex, so I'll be the one taking the load, and I'm fine with it. >> Images have the absolute minimal content possible. It's only qemu binaries, >> artifacts (roms, keymap, ...), and libraries. There is no shell or any other >> tool included. As a result, images have a size from 149MB (v0.12.0) to 1.48GB >> (v11.1.2). >> > > No shell means the first thing to do if one wants to debug the image is > to rebuild with a shell in. Not sure how frequent it will be, maybe it's > ok like this. > We could leave a base system, for only ~100MB per image, which is not the end of the world (+10% in size). Personally, I appreciate to have no shell, it reduces possibility of exploit when running an older QEMU having CVEs. >> This series adds 3 pieces: >> - a unique dockerfile to build any QEMU release. User has to provide an >> explicit >> Ubuntu version when building a given QEMU version. > > This is the tricky part. We'll be carrying code (script+dockerfile) that > only works on master. If we tag today and tomorrow the old distro repo > breaks, we obviously cannot fix it retroactively. So we need to be > careful of where we direct the maintenance effort. > > 1) I'd suggest first of all to keep the release image entirely separate > from the ubuntu image. Treat release.docker as we treat the other > dockerfiles and update it to work for the current release without > looking at past ones. Have it clone, checkout, build and gather > deps. Allow the configure to be tweaked via parameter in case we need to > disable something in an older build. > > The script would then build a distro image (or dockerfile) with the > knowledge that it has about ubuntu depending on the QEMU tag vs. ubuntu > version combination. This would allow us to track the cludges more > precisely instead of "some ancient distro" as the dockerfile currently > says. > > This is more of a layering concern and how easy it will be to drop/add > version-specific fixes. > IIUC I think that's the approach Fabiano took, to use Dockerfile from previous versions, and the conclusion was that it requires some seds and hacks to have something that work. Internet state is not immutable. IMHO, building previous QEMU with past Dockerfiles is doomed to fail. Only thing you can control/guarantee is that "current dockerfile on master works". > 2) I wonder if the usage of apt-get build-dep might be a convenience > trap. In theory, some of the adaptations that are required (such as > tweaking dependencies) have already been done by us when working on that > development window. If we take the dockerfiles from the git tag, those > changes don't need to be done again and for the issues that didn't exist > at the time, we can map them to the git tag instead of ubuntu version; > (we tend to know more about QEMU releases than ubuntu releases). > > Another issue with buid-dep is that it lists _ubuntu package_ > dependencies. The distro can change how it builds the package without us > noticing. There is already some work done by lcitool, I imagine that it > would then be duplicated. Or worse(!) be different because build-dep > might be listing way more packages that what we need for the default > build. > > This is more of a push towards using existing infra because those pieces > are already looked after for other purposes. > >> - A script build_release_container.sh which automatically detects which >> ubuntu >> version a given release should be buildable on (based on date). It works >> great, and the heuristic works for all our versions. >> - a script generate_release_links.sh which creates wrapper scripts >> automatically >> using prebuilt images (hosted on my dockerhub). >> Sure, lcitool could work to express all that. Would I like to spend time to rewrite all the missing bits in yaml when debian did it for me? not really. > > It would be nice if these two could take any hash, instead of just a > tag. This is one of the things that will depend on what you intend to > achieve with this series. > Very easy, it just needs a non shallow clone. --- After reading and answering to this message, I feel there are two topics we can discuss: 1. the current implementation 2. what would we like 1. Personally, I just posted this series as an example of "yes it's possible with very limited amount of code", and I don't mind having something completely different. I feel it's probably not worth reviewing every line at this point. 2. The biggest question seems to be the direction with: 'do we want to provide a single dockerfile that covers all versions' (a) VS 'having a dockerfile at a time of history for current version' (b). I think (b) is what we have now (current ubuntu/suse/debian/alpine image works for current revision, since it's used in CI), and it was already proven it fails from Fabiano's feedback. It seems to be that's what you propose also from your answer above. This series goes in another direction (a), adding a unique dockerfile covering all versions, independently of all the dockerfiles we have now. If we agree (a) is a better direction, unique dockerfile approach can be vastly simplified by restricting ourselves to qemu >= 3.1.0. If not, no hard feelings, it's just a proposal. Regards, Pierrick
