Support VZFileHandleNetworkDeviceAttachment

[AkihiroSuda]

Virtualization.framework provides built-in support for vmnet.framework (without root, for the NAT (shared) mode).

However, it has some drawbacks compared to socket_vmnet:

• VZNATNetworkDeviceAttachment doesn't support custom IP range
• VZBridgedNetworkDeviceAttachment requires the com.apple.vm.networking entitlement, which requires contacting to an Apple representative.

So, it still makes sense to support socket_vmnet for VZ.

VZFileHandleNetworkDeviceAttachment can be used for this, but its protocol is incompatible with QEMU. (DGRAM sock, without the uint32be length header)

Context:

• vz: support "lima: shared" networking using VZNATNetworkDeviceAttachment lima#1206 (comment)

---

Probably, CLI will be like socket_vmnet unix:///var/run/socket_vmnet unixgram://var/run/socket_vmnet.unixgram to cover both QEMU socket and VZ socket in a single process (so as to avoid complicating the sudoers file too much)

[balajiv113]

@AkihiroSuda
If this is not taken up i can give a try with this

[AkihiroSuda]

@balajiv113 Thanks

[balajiv113]

@AkihiroSuda - I did some progress on this, on working had a thought about one other way,

What if we write a Pipe mechanism to translate vz packets to qemu like packets ?? If we do this, we don't need any changes in socket_vmnet / gvisor. Any network that support qemu should be supported here as well.

translate vz packets to qemu like packets
Thought of doing the following,

1. Dial to a unix sock and get conn
2. create sock pair for dgram
3. read from dgram and write to unix sock with header
4. read from unix sock and write to dgram without header

One con i could see might drop a bit in performance due to this pipe mechanism but sure it should not be high. Please put down your thoughts on this. If this is good, i can provide this support rather than socket_vmnet changes

[AkihiroSuda]

Sounds good as a workaround, but eventually we have to eliminate that pipe for better performance