--socket does not work with qemu

[DUOLabs333]

1. Run sudo ./build/vmnet-helper --socket connect.sock --interface-id 2835E074-9892-4A79-AFFB-7E41D2605678 --operation-mode=shared
2. In another tab/window/etc., run

sudo env "DYLD_FALLBACK_LIBRARY_PATH=qemu/lib" qemu/bin/qemu-system-aarch64 \
-M virt,accel=hvf -m 3G \
-cpu host \
-drive file=debian-12-nocloud-arm64.qcow2 \
-netdev stream,id=vlan,addr.type=unix,addr.path=/Users/system/vmnet-helper/connect.sock,server=off \
-device virtio-net,netdev=vlan,mac=5a:94:ef:e4:0c:ee \
-smp 4 \
-nographic \
-bios edk2-aarch64-code.fd \
-boot menu=off

3. See that if you try to run iperf in the guest, you get iperf3: error - unable to connect to server: Network is unreachable and the output of vmnet-helper is stuck at INFO [main] waiting for client on "connect.sock"

I also tried reversing 1 and 2 (so that the QEMU process is started first, opening a listening socket, rather than connecting to an existing one), but the outcome remains the same.

[nirs]

@DUOLabs333 This is a known limitation in qemu - -netdev stream cannot be used with vmnet-helper since it is not a datagram socket.

The only way we can integrate with qemu is using -netdev dgram, and only with local.type=fd. local.type=unix is unidirectional and can be used only for connect 2 qemu processes or another application using 2 sockets. For vmnet helper we need a connected datagrapm socket that we can read and wrtie.

This is documented in the testing framework here:

vmnet-helper/testing/vm.py

Line 221 in 101f109

elif self.socket is not None:

We are missing developer documentation about this here:
https://github.com/nirs/vmnet-helper/blob/main/docs/integration.md#starting-the-helper-with-a-unix-socket

We already have an example showing how to use qemu with vmnet-run - it uses vmnet-helper --fd internally to share a connected datagram socket between vmnet-helper and qemu:
https://github.com/nirs/vmnet-helper/blob/main/examples/qemu.sh

Note also that you get poor performance with qemu due to the inefficient way it handles packets with dgram device.
https://github.com/nirs/vmnet-helper/blob/main/performance/results/2026-02/M3/plot/drivers/shared.png

If you don't have qemu specific functionality you should use vfkit to get 5.5x faster networking, faster boot, and much quiker installation:
https://github.com/nirs/vmnet-helper/blob/main/performance/results/2026-02/M3/plot/drivers/shared.png

Do you want to contribute the missing documentation? It can be a simple alert about qemu limitations.

[DUOLabs333]

Oh, thanks!

Note also that you get poor performance with qemu due to the inefficient way it handles packets with dgram device

Yeah, I suspect this (one of my programs uses networking to communicate between the guest and the host, and requires extremely fast communication --- at best I get 2 Gbits/s, and I'm not sure whether this is because of qemu or of vmnet itself. I tried changing some basic things in qemu (mostly implementing batching in the vmnet netdev), but I wasn't able to get any improvement --- I'm currently seeing if using an ivshmem device, paired with a socket for metadata, yields better results).

Since I'm assuming you've done some investigation into QEMU for you to notice that dgram sockets are slow, do you have any place in QEMU I should look at to improve (I'm focusing on virtio-net-pci, but I'm sure there are more general fixes elsewhere)?

Unfortunately, I'm on Big Sur, so I don't believe vfkit is available to me (plus, I have some use cases that only work with QEMU at the moment).

[nirs]

macOS version 11 (Big Sur) is not supported by vmnet-helper - we support macOS 14 or later (like vfkit, krunkit, and others).

If you need qemu, you will get best results with qemu builtin vmnet (-netdev vmnet) - but it requires root.

From qemu-system-aarch64 -h:

-netdev vmnet-shared,id=str[,isolated=on|off][,nat66-prefix=addr]
         [,start-address=addr,end-address=addr,subnet-mask=mask]
                configure a vmnet network backend in shared mode with ID 'str',
                configure the address range and choose a subnet mask,
                set IPv6 ULA prefix (of length 64) to use for internal network,
                isolate this interface from others with 'isolated'

You can also try to tweak vmnet-helper build to support older macOS. See the build config:
https://github.com/nirs/vmnet-helper/blob/main/building/x86_64.ini