On 7/13/2026 1:32 AM, Daniel P. Berrangé wrote: > On Fri, Jul 10, 2026 at 11:20:37AM -0700, Pierrick Bouvier wrote: >> On 7/10/2026 4:52 AM, Daniel P. Berrangé wrote: >>> On Fri, Jul 10, 2026 at 12:47:28PM +0100, Alex Bennée wrote: >>>> Daniel P. Berrangé <[email protected]> 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 >> >> Is it me or did we incredibly derailed from original issue which was: >> "It was fast to query which container engine is available, and now it's >> 5-10 times slower to accommodate toolbox workflow where podman is >> available but not really available?" >> I agree it's sad to have several ways to set container engine, but it's >> absolutely not related to the current issue. > > It is relevant because that difference in speed is not something that > should be noticable unless something is repeatedly probing over & over > again which should not be done. > >> Daniel, since you introduced the slow check path with podman info for >> your personal need, I would appreciate if it's something you could fix also. > > I'll looking into the missing caching. >
Thanks! > With regards, > Daniel
