This series was inspired by a recent post from Fabiano to provide container
images for migration tests:
https://lore.kernel.org/qemu-devel/24d04a1f-344d-4b90-a307-b582dd9a1128@oss.qualcomm.com/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.

The oldest functional distro we can find nowadays is ubuntu 14.04. Because of
this, the oldest QEMU release we can build is v1.6.1. Previous ones require an
environment we can't get easily today.

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 240MB (v1.6.1) to ~1GB
(v11.0.0).

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.
- 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).

TLDR:
$ ./scripts/build_release_container.sh v1.6.1
$ podman run -it --rm qemu/v1.6.1 qemu-system-arm --version

$ ./script/generate_release_links.sh qemu-time-machine
$ ./qemu-time-machine/v1.6.1/qemu-system-arm --version
QEMU emulator version 1.6.1, Copyright (c) 2003-2008 Fabrice Bellard
$ ./qemu-time-machine/v11.0.0/qemu-system-arm --version
QEMU emulator version 11.0.0 (v11.0.0)
Copyright (c) 2003-2026 Fabrice Bellard and the QEMU Project developers

v2
--

- fix generate_release_links.sh: was missing userns option for podman
- dockerfile: cleanup "|| true" and replaced with proper ifs

Pierrick Bouvier (3):
  tests/docker/dockerfiles: add release.docker
  scripts: add build_release_container.sh
  scripts: add generate_release_links.sh

 scripts/build_release_container.sh      | 59 ++++++++++++++++++++
 scripts/generate_release_links.sh       | 71 +++++++++++++++++++++++++
 tests/docker/dockerfiles/release.docker | 69 ++++++++++++++++++++++++
 3 files changed, 199 insertions(+)
 create mode 100755 scripts/build_release_container.sh
 create mode 100755 scripts/generate_release_links.sh
 create mode 100644 tests/docker/dockerfiles/release.docker

-- 
2.43.0

On 10/11/2026 9:27 AM, Pierrick Bouvier wrote:
> This series was inspired by a recent post from Fabiano to provide container
> images for migration tests:
> https://lore.kernel.org/qemu-devel/24d04a1f-344d-4b90-a307-b582dd9a1128@oss.qualcomm.com/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.
> 
> The oldest functional distro we can find nowadays is ubuntu 14.04. Because of
> this, the oldest QEMU release we can build is v1.6.1. Previous ones require an
> environment we can't get easily today.
> 
> 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 240MB (v1.6.1) to ~1GB
> (v11.0.0).
> 
> 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.
> - 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).
> 
> TLDR:
> $ ./scripts/build_release_container.sh v1.6.1
> $ podman run -it --rm qemu/v1.6.1 qemu-system-arm --version
> 
> $ ./script/generate_release_links.sh qemu-time-machine
> $ ./qemu-time-machine/v1.6.1/qemu-system-arm --version
> QEMU emulator version 1.6.1, Copyright (c) 2003-2008 Fabrice Bellard
> $ ./qemu-time-machine/v11.0.0/qemu-system-arm --version
> QEMU emulator version 11.0.0 (v11.0.0)
> Copyright (c) 2003-2026 Fabrice Bellard and the QEMU Project developers
> 
> v2
> --
> 
> - fix generate_release_links.sh: was missing userns option for podman
> - dockerfile: cleanup "|| true" and replaced with proper ifs
>
sent v3, adding support for ubuntu 12.04, and thus lowering older
revision until v0.12.0:
https://lore.kernel.org/qemu-devel/20261014005338.34657-1-pierrick.bouvier@oss.qualcomm.com/T/#t

Regards,
Pierrick

On Sun, Oct 11, 2026 at 04:27:34PM +0000, Pierrick Bouvier wrote:
> This series was inspired by a recent post from Fabiano to provide container
> images for migration tests:
> https://lore.kernel.org/qemu-devel/24d04a1f-344d-4b90-a307-b582dd9a1128@oss.qualcomm.com/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.
> 
> The oldest functional distro we can find nowadays is ubuntu 14.04. Because of
> this, the oldest QEMU release we can build is v1.6.1. Previous ones require an
> environment we can't get easily today.
> 
> 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 240MB (v1.6.1) to ~1GB
> (v11.0.0).
> 
> 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.
> - 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).
> 
> TLDR:
> $ ./scripts/build_release_container.sh v1.6.1
> $ podman run -it --rm qemu/v1.6.1 qemu-system-arm --version
> 
> $ ./script/generate_release_links.sh qemu-time-machine
> $ ./qemu-time-machine/v1.6.1/qemu-system-arm --version
> QEMU emulator version 1.6.1, Copyright (c) 2003-2008 Fabrice Bellard
> $ ./qemu-time-machine/v11.0.0/qemu-system-arm --version
> QEMU emulator version 11.0.0 (v11.0.0)
> Copyright (c) 2003-2026 Fabrice Bellard and the QEMU Project developers

This looks pretty useful and also generic, thanks for working on it.

-- 
Peter Xu

On 10/13/26 2:09 PM, Peter Xu wrote:
> On Sun, Oct 11, 2026 at 04:27:34PM +0000, Pierrick Bouvier wrote:
>> This series was inspired by a recent post from Fabiano to provide container
>> images for migration tests:
>> https://lore.kernel.org/qemu-devel/24d04a1f-344d-4b90-a307-b582dd9a1128@oss.qualcomm.com/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.
>>
>> The oldest functional distro we can find nowadays is ubuntu 14.04. Because of
>> this, the oldest QEMU release we can build is v1.6.1. Previous ones require an
>> environment we can't get easily today.
>>
>> 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 240MB (v1.6.1) to ~1GB
>> (v11.0.0).
>>
>> 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.
>> - 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).
>>
>> TLDR:
>> $ ./scripts/build_release_container.sh v1.6.1
>> $ podman run -it --rm qemu/v1.6.1 qemu-system-arm --version
>>
>> $ ./script/generate_release_links.sh qemu-time-machine
>> $ ./qemu-time-machine/v1.6.1/qemu-system-arm --version
>> QEMU emulator version 1.6.1, Copyright (c) 2003-2008 Fabrice Bellard
>> $ ./qemu-time-machine/v11.0.0/qemu-system-arm --version
>> QEMU emulator version 11.0.0 (v11.0.0)
>> Copyright (c) 2003-2026 Fabrice Bellard and the QEMU Project developers
> 
> This looks pretty useful and also generic, thanks for working on it.
> 

Is there something specific you would need for migration purpose that is 
not covered yet?

If we go in this direction, and decide to host official images 
somewhere, we could even add the wrappers by default for all builds, so 
everyone could have ./build/releases/vX.Y/qemu-* scripts generated by 
default when typing make or ninja.

Regards,
Pierrick

On Tue, Oct 13, 2026 at 02:16:47PM -0700, Pierrick Bouvier wrote:
> Is there something specific you would need for migration purpose that is not
> covered yet?
> 
> If we go in this direction, and decide to host official images somewhere, we
> could even add the wrappers by default for all builds, so everyone could
> have ./build/releases/vX.Y/qemu-* scripts generated by default when typing
> make or ninja.

To me, the build container would already simplify things auto-select the
base image, making the build smooth; I don't have personal use yet for
official images.

I think Fabiano's testing env is better than mine using this similar
approach, it's just that I hardly hit a bug, especially, QEMU bug in the
past, that breaks migration ABI in a way that A<=>B works, B<=>C works, but
A<=>C fails.

Here, if we make A=master, B=release-N-1, C=release-N-2, then the migration
compat test in CI (on whatever migration-test covers... obviously not full
device coverage yet) guarantees A<=>B, and then B<=>C too in previous dev
cycle, and so on.  I expect A<=>C works.

I am assuming the ABI compatibility chains like that until very old qemus
when Fabiano introduced the compat test.  Then I hoped we had good coverage
even without a large matrix of qemu versions to test.

I only need to do a custom build in extremely rare cases.  There, patch 2
should be very helpful already.

So I'll leave that to you all to decide how far we go, or whether we need
to host official images.

Thanks,

-- 
Peter Xu

On 10/13/2026 4:20 PM, Peter Xu wrote:
> On Tue, Oct 13, 2026 at 02:16:47PM -0700, Pierrick Bouvier wrote:
>> Is there something specific you would need for migration purpose that is not
>> covered yet?
>>
>> If we go in this direction, and decide to host official images somewhere, we
>> could even add the wrappers by default for all builds, so everyone could
>> have ./build/releases/vX.Y/qemu-* scripts generated by default when typing
>> make or ninja.
> 
> To me, the build container would already simplify things auto-select the
> base image, making the build smooth; I don't have personal use yet for
> official images.
> 
> I think Fabiano's testing env is better than mine using this similar
> approach, it's just that I hardly hit a bug, especially, QEMU bug in the
> past, that breaks migration ABI in a way that A<=>B works, B<=>C works, but
> A<=>C fails.
> 
> Here, if we make A=master, B=release-N-1, C=release-N-2, then the migration
> compat test in CI (on whatever migration-test covers... obviously not full
> device coverage yet) guarantees A<=>B, and then B<=>C too in previous dev
> cycle, and so on.  I expect A<=>C works.
> 
> I am assuming the ABI compatibility chains like that until very old qemus
> when Fabiano introduced the compat test.  Then I hoped we had good coverage
> even without a large matrix of qemu versions to test.
>

Thanks for the insight. I don't expect we need to do anything with qemu
1.X, but it was free to go until there, so why not.

> I only need to do a custom build in extremely rare cases.  There, patch 2
> should be very helpful already.
>

Which kind of extra builds do you need to do?

If you find it useful, we can add a container build-arg for qemu
configure options (empty by default), so you can build with debug, or
any other option that might be useful to you.

So it would be something like:
./scripts/build_release_container.sh v11.1.0 --any --option --you --like

> So I'll leave that to you all to decide how far we go, or whether we need
> to host official images.
>

We can see what other people think.
I think it's a nice convenience, and I had to build all revisions to
test the thing anyway.
In case using prebuilt images is an issue, I would be ok to modify
wrappers to a build & run action, instead of a pull.

> Thanks,
> 

Regards,
Pierrick