Re: [PATCH v2 2/4] tests/docker: add support for podman remote access

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Jul 10, 2026 at 12:47:28PM +0100, Alex Bennée wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> (added Edgar for Microblaze)
> 
> > On Thu, Jul 09, 2026 at 09:24:12AM -0700, Pierrick Bouvier wrote:
> >> On 7/9/2026 9:13 AM, Daniel P. Berrangé wrote:
> >> > On Thu, Jul 09, 2026 at 07:48:14AM -0700, Pierrick Bouvier wrote:
> >> >> On 2/10/2026 8:35 AM, Daniel P. Berrangé wrote:
> >> >>> When a developer's environment is already within a podman container it
> >> >>> is not possible to use 'podman' again to create containers. It will
> >> >>> usually result in wierd errors such as:
> >> >>>
> >> >>>   Error: fatal error, invalid internal status, unable to create a new pause process: cannot re-exec process to join the existing user namespace. Try running "podman system migrate" and if that doesn't work reboot to recover
> >> >>>
> >> >>> Podman offers the ability to talk to a daemon outside the container,
> >> >>> however, which could be leveraged by QEMU.
> >> >>>
> <snip>
> >> >> Taking a look at why tcg tests are slow to compile, I reached this
> >> >> commit. It seems like that calling 'podman info' is 5 to 10 times slower
> >> >> than calling 'podman version'.
> >> >> Thus, a container run now takes +1s when it was 0.2 before.
> >> > 
> >> > Hmmm, but we call 'docker.py probe' in configure and cache the result,
> >> > so that probe should only be done once.  0.2 vs 1s is just noise in
> >> > the context of configure.
> >> > 
> >> > That you're seeing any negative effects suggests that we've got
> >> > something not using the cached probe result, which we should fix.
> >> >
> >> 
> >> Not really, docker.py --engine X still calls X info.
> >> 
> >> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/docker/docker.py#L675
> >> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/docker/docker.py#L78
> >> 
> >> Maybe the fix is to remove the check if user specified an explicit
> >> engine. But in this case, there is a problem with podman-remote not
> >> being detected anymore.
> >> 
> >> We can fix this by introducing engine=podman-remote, and skip the check
> >> if engine is explicitly set.
> >> What do you think?
> >
> > Urgh, so i see now we have two code paths / make variables
> >
> >   RUNC=podman --remote
> >   CONTAINER_ENGINE=auto
> >
> > Sometimes we'll invoke docker.py --engine $(CONTAINER_ENGINE)
> > and sometimes we'll directly invoke $(RUNC).
> 
> Yeah that could do with cleaning up. I suspect the only places we
> actually still need the script is where we are doing binfmt_misc enabled
> containers unless there is a way to emulate the copying of qemu into the
> container with a plain call? Maybe all the systems now have the
> persistent flags which would skip this.

Yeah, I'd be inclined to say this is a job for the distros to have
qemu-user integration, and simplify our life. THe docker.py script
always confuses me.  We could choose podman vs podman --remote vs
docker simply in the meson.build file, as we do for other dev env
choices.

> The toolchain case could be skipped if we could find hosted compilers
> for microblaze. However I do see we have a patch in there.
> 
> >
> > The result of "probe" cannot be fed back in to "--engine" which
> > is a bit of a mess. I think the "engine" concept should not be
> > exposed on the cli, and instead have a "--runc" arg which takes
> > the full arg(s), since we need probe to report the runc args
> > for other reasons.
> >
> > With regards,
> > Daniel
> 
> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|