Restore qemu support on macOS optionally

[ecky-l]

Feature request description

With podman 5.x, the podman machine's are now based on applehv native hypervisor. While this might have advantages, it only works for more recent versions of macOS. Users of old macOS versions, i.e. before Ventura, are out of the game, unless they use an older podman version 4.x.

I don't know if there are particular technical reasons to have it dropped, but qemu is in general working fine on recent and old macOS versions. Maybe the native applehv machines have some advantages, which are not available with qemu, but I think most users could live with that in preference of using an outdated podman version.

Suggest potential solution

Reenable the qemu support in form of a driver or config setting. The default could still be applehv (on recent macOS), but as a fallback or if otherwise desired, the user should be able to switch the virtualization layer to qemu.

Have you considered any alternatives?

Using an old version of podman, prior 5.x works as an alternative. But it has the disadvantage, that these old versions run out of support and won't have the latest features, moving forward.

Additional context

docker-machine (https://github.com/docker/machine) had the possibility to switch "drivers" for different virtualization engines.

[Luap99]

qemu support on macos as it is was a big maintenance problem, it broke often and testing anything machine related is a lot of work.
Also macOS 12 will be EOL later this year anyway so putting in a ton of work just to re-enable does not sounds reasonable to me.
cc @baude @ashley-cui

also see #22121

[jakecorrenti]

I agree with @Luap99 here. If macOS 12 is going EOL later this year, and the minimum version we support is macOS 13, then I don't see it being worth the development/testing/support burden.

[ecky-l]

But still there are people who use the outdated macOS versions, even when its EOL. And others might prefer qemu over applehv for other reasons, even on current macOS versions.
Qemu is version- and even platform agnostic, after all.

[jakecorrenti]

I understand. However, we had to weigh the pros and cons and it was decided to deprecate QEMU support

[rhatdan]

Does krunkit work, or does this require newer versions of Mac as well?

[jakecorrenti]

krunkit requires newer versions of Macs because it requires an Apple Silicon processor

[afbjorklund]

@ecky-l
You can use Lima, for this.

It allows you to select your machine driver and volume driver,
as well as selecting your cpu architecture and operating system.
It's also a replacement for Vagrant, which is no longer Open Source,
so that you can customize your machine template with provisioning.

Podman Machine is about providing the best podman appliance for you,
so more similar to Docker Desktop (though with a different license...)
Full disclosure: I am the author of the original podman-machine (v1),
and a current maintainer in the Lima project (including the Lima GUI)

brew install lima

limactl start template://podman

Will get you the latest Podman.

[arixmkii]

Even if QEMU support being restored it will not be for the case of EOL OS versions.

But still there are people who use the outdated macOS versions, even when its EOL.

QEMU has deprecation process supporting only 2 latest OS releases or something. So, the QEMU support in general for EOL OS version can be considered as a given only for older versions of QEMU and supporting some outdated QEMU version would be a no go due to security considerations.

If you are forced to stay longer with old OS it is probably reasonable to consider some version of the application, which supported it and stay with it.

[ecky-l]

@afbjorklund , thanks I will try that :).

@ others, I see.
Still I think it would make sense to support QEMU, not in particular for older OS versions, but in general. QEMU has the advantage of being platform agnostic, and the ability to emulate various architectures in addidtion to virtualizing (plus, i.e. emulate x86_64 container images on arm64 host architecture in an arm64 VM... can applehv do that?). I had this requirement a few times on an M1 mac book, when there was no arm64 container image available.
But I also understand that it increases the testing/support effort, thus has to be out-weighted against the advantages.

As for the support on older platforms, well, in 2-3 years the macOS Monterey will be obsolete for other reasons too... then I have to decide anyway, whether I install Linux on the hardware, or experiment with Open Core Legacy Patcher, or buy new hardware. Until then I can use podman 4.9.5... so nevermind.

[rhatdan]

Podman does not have the contributors or time to maintain qemu, so I am going to close this with a Won't fix.

[rhatdan]

You are welcome to continue the conversation here.

[arixmkii]

@ecky-l

can applehv do that?

You can run amd64 containers in applehv machine with either QEMU guest architecture or Rosetta 2 in Linux VM (both via binformat enablement) and both options should be now supported in latest Podman releases.

Emulation of an entire guest architecture machine is a nice feature, but the performance hit make it not a great choice for containerized workloads, where you want to run many processes. For me it always felt like a feature for embedded dev scenarios and this has no connection to Podman.

I had this requirement a few times on an M1 mac book, when there was no arm64 container image available.

You need to go and try if it will work for you. I had both success stories (for very intensive and heavy workloads) and failure stories (even for very simple workloads), depending on which amd64 features are utilized by the app you need to run.

[afbjorklund]

QEMU has the advantage of being platform agnostic

Previously we used VirtualBox, but it is arch challenged

[ecky-l]

Emulation of an entire guest architecture machine is a nice feature, but the performance hit make it not a great choice for containerized workloads, where you want to run many processes. For me it always felt like a feature for embedded dev scenarios and this has no connection to Podman.

Well, I would consider the whole podman machine thing only for dev scenarios. For production I would not rely on that... given the fact that these podman machines are quite ephemeral in my experience ;).

Podman does not have the contributors or time to maintain qemu, so I am going to close this with a Won't fix.

Fair enough.

But one more idea for an alternative implementation: wouldn't it make sense to decouple the podman client and the podman machine? The machine component could be implemented as a shared lib, that is plugged in at runtime and provides the podman machine subcommand. So if installed together, this would work the same way as now.
If only the podman client is installed, the user would need to provide a VM by other means as the backend for podman, with the proper Port- and Volume Mappings in place. He could then use any virtualization layer of choice (even VirtualBox), or lima, etc.. This is an advanced use case, of course.

[rhatdan]

Well podman (-remote) can talk to any podman service running within a VM now. So it would kind of work. Sharing volumes (directories) and opening ports on the local machine would be broken. Podman machine uses gvproxy to communicate from the container to the host to open and close ports.

There are potentially other issues I am sure.

[afbjorklund]

wouldn't it make sense to decouple the podman client and the podman machine?

It was a separate command (podman-machine), that had plugins for the drivers...