Consider adding --device virtio-net,type=unixgram for krunkit compatibility

[nirs]

krunkit added new way to work with unix datagram socket:
containers/krunkit#63

--device virtio-net,type=unixgram,path=/path/to/socket.sock,mac=...,offloading=on,vfkitMagic=on

This device creates the same configuration as:

--device virtio-net,unixSocketPath=/path/to/socket.sock,mac=...

But unlike unixSocketPath it

• supports multiple devices
• does not enable offloading by default (7 times faster host-to-vm performance with vment-helper)
• does not send the vfkit magic (VFKT) by default (not needed with vmnet-helper)

krunkit supports also other types like:

--device virtio-net,type=unixstream,path=/path/to/socket.sock,mac=...

This is required to use passt or socket_vment.

For vfkit type=unixstream is not relevant since the virtualization framework supports only unix datagram socket, but type=unixgrram is matches.

The offloading option is not relevant to vfkit since the virtualization framework does not have a way to enable offloading and using makes performance much worse.

The vfkitMagic flag makes sense since it is needed only for gvproxy and can be removed in future version of gvproxy.

Adding similar configuration will make it easier to use vfkit and krunkit.

Suggested change

krunkit compatible device:

--device virtio-net,type=unixgram,path=/path/to/socket.sock,mac=...,vfkitMagic=on

device without optional configuration (not compatible with krunkit):

--device virtio-net,path=/path/to/socket.sock,mac=...

• nat: guest network traffic will be NAT'ed through the host. This is the default
• path: path to unix datagram socket, alias of unixSocketPath
• fd: unix datagram socket file descriptor
• mac: mac address
• 'type: (Optional) the only option is unixgram`, mainly for compatibility with krunkit when using path= and fd= options.
• vfkitMagic: (Optional) send vfkit magic packet (needed for gvproxy)

Internally no change is needed except making the vfkit magic packet optional.

Issues:

• type does not make sense for the nat option.

[nirs]

/cc @cfergeau

[cfergeau]

VFKT will be optional in gvisor-tap-vsock once containers/gvisor-tap-vsock#530 merges.
It makes sense to add a vfkitMagic boolean to the command line to help with the transition.
Does krunkit also support unixSocketPath=/path/to/socket.sock? or only type=unixgram,path=/path/to/socket.sock?

[nirs]

Does krunkit also support unixSocketPath=/path/to/socket.sock? or only type=unixgram,path=/path/to/socket.sock?

unixSocketPath=/path/to/socket.sock is supported for backward compatibility with existing users, but the recommended configuration is type=unixgram or type=unixtream since these support both path= and fd= and allow enabling offloading and vfkitMagic which are disabled by default.

[cfergeau]

since vfkit does not need offloading, do we need to handle it at all? I assume it’s going to be better for you if we accept it but ignore it?

[nirs]

since vfkit does not need offloading, do we need to handle it at all? I assume it’s going to be better for you if we accept it but ignore it?

If we want to support the new type= network, we should support offloading=false. This will make it easier to use both krunkit and vkfit in the same tool without offloading.

If the user specifies offloading=true we should fail since we cannot satisfy this request. Performance testing shows that configuring offloading in the vmnet interface is always 2 times slower with vfkit, and some operation modes not (host) do not work at all with offloading. We don't want to lie to users about vfkit capabilities.

Maybe Apple will support offloading in future version of virtualization framework. Having the offloading option in the command line interface will make it easy to enable in vfkit.