Change QEMU netdev to Unix domain socket

[arixmkii]

Fixes #21544

This change migrates to new QEMU stream netdev added in 7.2.0. It also unifies how gvproxy is used in QEMU and AppleHV.

This change will require manual fixes to QEMU machine configurations migrated from 4.x, but 5.0 version is the only good point to do so. My previous work was with preserving old FD code, but it makes the codebase really messy.

It replaces my previous work from:
#21252
#17473
#18488

Does this PR introduce a user-facing change?

QEMU machine uses Unix domain socket netdev device type

[NO NEW TESTS NEEDED]

[arixmkii]

I'm open to split this PR into separate commits like:

• bugfixes
• migration to Unix domain socket netdev
• add QEMU on Windows support

[arixmkii]

This passed full e2e suite on a Windows machine.

[arixmkii]

@baude @n1hility @jakecorrenti Could you take a look as you were doing reviews of my previous PRs on the same topic.

[arixmkii]

Removed Windows machine provider from this commit - reduced the scope of changes to refactoring only.

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[arixmkii]

@baude do you see this getting into release or this change will not make it anyway?

[jakecorrenti]

code LGTM but I want a @baude head nod

[arixmkii]

Rebased to latest main to use extracted wait for the socket function. This changeset should be now as compact as possible.

[arixmkii]

If this is being accepted, will also allow to close #18314 as "won't implement", as, so far, there were no newer features identified, which are breaking for the Podman machine.

[arixmkii]

@baude did you by any chance have time to take a look at this?

[baude]

@baude did you by any chance have time to take a look at this?

looking now!

[baude]

my one concern is that business with the fd being passed as an extrafile was crucial at one time. does this approach actually mitigate the need or ignore it ?

[arixmkii]

It was the only option before QEMU 7.2.0 (QEMU 7.2.0 is now the oldest LTS still receiving fixes in upstream QEMU).

This is one of the recaps of the changes why it had become possible to use AF_UNIX directly https://john-millikin.com/improved-unix-socket-networking-in-qemu-7.2

I can dig the PATCH series from QEMU mailing list as well. IIRC the main reason it was not exposed as netdev before, because of the incomplete parser for parameters, not that it was technically an issue to use AF_UNIX netdev directly.

[arixmkii]

Here is the PATCH with details from the author https://lists.gnu.org/archive/html/qemu-devel/2022-10/msg03516.html I'm not sure if it is the latest revision, but the main idea was not changed through revision versions, only fixes and adjustments were applied. It is mostly old socket netdev combined with new QAPI for parameter input.

[arixmkii]

QEMU 7.2.0 has been released in December, 2022 (https://www.qemu.org/2022/12/14/qemu-7-2-0/). My assumption was that this is old enough to become the baseline for the next generation Podman Machine (where compatibility breakages already happening - like removing QEMU support from official MacOS version, where all these machines will be eliminated and the storage format changes in general).

If this is still a no go I would probably rework this into moving this change into Windows specific part and keeping Unix part with FDs. This is the part which makes current QEMU machine code not cross platform, but there are multiple ways mitigating this.

[arixmkii]

To provide a summary:

Pros:

• less magical, podman binary doesn't interact with gvproxy and QEMU processes only via API (command line, pidfiles and process API, QMP protocol, ready socket - no magical FD allocated is transferred between processes)
• the code is as close as it could be to applehv
• code will become really cross platform

Cons:

• breaking for old machines (they could be fixed via editing command line in config)
• requires QEMU 7.2.0+ (7.2.0 is the only old LTS in upstream, so, unless distributions provide their own fixes it should be the minimal QEMU version in a wild one would reasonably care about)

@jakecorrenti @baude I listed these pros and cons and provided technical details in my previous comment, now, I will leave it for your team to decide if this is a good fit for Podman now or not. Thank you a lot for your time and reviews!

[Luap99]

breaking for old machines (they could be fixed via editing command line in config)

Podman 5.0 breaks the config file anyway so this shouldn't be an issue. Only we if we decide to implement some migration we need to keep this in mind but I don't think we will.

[baude]

/approve
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: arixmkii, 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

[baude]

@arixmkii is this rebased to the latest (as of today) main branch ?

[arixmkii]

@baude yes, it is only 2 commits behind main.

[baude]

ill babysit and assume this is a flake.