On 10/12/2026 1:18 AM, Daniel P. Berrangé wrote: > 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 > > snip > >> 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. > > Yes, in general building old QEMU on new distros periodically > hits trouble. If building old QEMU, better reliability is > achieved by using a distro release that was from the same > timeframe as QEMU. Is using containers targetting such old > distro versions not an option ? The tests/docker/dockerfiles > from the old QEMU branch ought to work ? >
Using containers image we had in tree would be nice, assuming they still work today and don't reference any url that disappeared. I see that, for ubuntu for instance, we targeted some mid-LTS releases (like 19.04), so apt urls should be changed to https://old-releases.ubuntu.com/. It's quite hard to achieve true portability in dockerfiles over time. As an alternative, this is an example of a single dockerfile that can build all our releases from 1.6.1 -> latest, using only LTS versions from 14.04 to 26.04: https://lore.kernel.org/qemu-devel/[email protected]/ > Our stable release branches have the same needs, and their > CI is using the container images from the old branches. > > How far back in time do you need/want to go for migration > testing ? Is it sufficient to merely target versions for > which mjt is still doing active maint work, so we can > expect the containers to still work. > > With regards, > Daniel Regards, Pierrick
