Set applehv as default darwin provider

[baude]

Podman 5 will not support QEMU on darwin anymore. This PR only changes the default from qemu to applehv. Code changes to enforce not supporting qemu will come later.

[NO NEW TESTS NEEDED]

Does this PR introduce a user-facing change?

The default machine provider for MacOS is the apple hypervisor

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: baude

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [baude]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rhatdan]

LGTM
@ashley-cui @Luap99 @mheon PTAL

[mheon]

/lgtm
/hold

[cgwalters]

The UX here will be that we start silently ignoring their old machine, right? Probably want to help them clean up old files perhaps?

[baude]

more cleanup will be needed but i want a more stable experience with applehv and the problems we are seeing. there will not be likely any migration supported machines from 4 -> 5 ... thats the official story; unofficially, we would like to do as much as we can.

[baude]

/hold cancel

[cgwalters]

@baude I'm digging into a few things and...can you (or someone) either link me to or briefly create a summary of why we did the switch to applehv vs qemu? What were the top problems with qemu?

The main thing I'm starting to hit is the lack of any standard way to inject credentials into a generic disk image with virtualization.framework. I am thinking of a way to hack things where we detect the root disk blockdev name in the initramfs and if it's a hardcoded rootwithvirtiofsmeta or something then we require a virtiofs mount to be provided and copy creds from it to the @initrd space.

(xref systemd issue 29175)

But with qemu we can just use the existing SMBIOS bits.

Edit: hmmm...I guess one thing here is that we're using 9p mounts on both Linux and MacOS...on Linux we should definitely be using virtiofsd instead, just needs some work similar to what I did similar to coreos/coreos-assembler#3428 in coreos-assembler. But we can't do that yet on MacOS because "our" virtiofsd doesn't run on MacOS - and the MacOS-owned one is part of Virtualization.Framework.

Wait wait...OK, actually we are also working on a different host-side implementation of virtiofs in https://github.com/containers/libkrun/tree/adb5eb1fb0a5b4643e249b5d1e29df0866776358/src/devices/src/virtio/fs ? And this was apparently forked a while ago from a distinct crosvm implementation?

(Total tangent here but I think it's confusing the new podman backend is called "applehv" and not "applevf" for example, because before qemu still used apple hypervisor...the new thing is really the "vf" part not the "hv" part)

[rhatdan]

QEMU was very unstable, particularly since anyone could push and broken update. Podman was regularly broken by qemu updates and the upstream community showed very little interest in supporting MAC.

Docker and CRC had already abandoned QEMU for similar reasons.

Another major reason was the support for virtiofsd which is not supported by QEMU but is via apple hypervisor. We see much better performance with it then Plan9 with QEMU.

Final reason was the emulation mode (Rosetta) for running X86 code on Arm systems is only supported by native hypervisor.

BTW I think in the future we might want to use krunvm rather then both of these since it gives us back the control, better support for virtiosfd, and GPU sharing inside of the VM with the host. But krunvm is not ready for prime time yet.