consider one vmnet interface per VM, datagram-based interface

[tamird]

Currently socket_vmnet spawns a single vmnet_interface

socket_vmnet/main.c

Lines 263 to 272 in f486d47

	iface = vmnet_start_interface(
	dict, q, ^(vmnet_return_t x_status, xpc_object_t x_param) {
	status = x_status;
	if (x_status == VMNET_SUCCESS) {
	print_vmnet_start_param(x_param);
	max_bytes =
	xpc_dictionary_get_uint64(x_param, vmnet_max_packet_size_key);
	}
	dispatch_semaphore_signal(sem);
	});

and takes on the responsibility of flooding all clients with all other clients' packets. This leads to #58.

We should consider an alternative design where the client-server interface is comprised of a file descriptor and metadata that allows the server to create a VM per client. This would remove the need to flood with packets, allow some VMs to be isolated from others, and generally expose the full generality of vmnet with better performance.

We should also move to datagram sockets as part of this redesign as they do not employ a framing protocol that requires 2 read calls per packet and makes it impossible to use vectorized reads.

[c-wicklein]

Greetings and salutations,

I find myself here as a UTM user after hitting a perceived limitation of QEMU, deciding I'll probably need to build QEMU myself to work on this limitation (described below), building a recent version of QEMU (9.1.2), and ending up stymied by the whole entitlements / provisioning profile / not even on your own MacBook debacle.

I've just tried working out how I might use socket_vmnet as an alternative to qemu-system-aarch64 having the necessary entitlements, but I'm not sure that it's possible, and this issue looks to be related. My current application of QEMU involves a pair of VMs running Linux for with four network interfaces per guest. Each guest has a first "shared" interface and three additional "host" interfaces. Using three distinct values with net-uuid, I have in effect directly cabled corresponding interfaces across the two VMs, i.e. enp0s9 to enp0s9, enp0s10 to enp0s10, and enp0s11 to enp0s11. (I want to use one VM to simulate a Linux server functioning as a router between a LAN and two different residential Internet service providers and the other to simulate its peers, i.e. other hosts on the LAN and two independent cable modems.). I understand this use-case doesn't work with socket_vmnet as I need upwards of four distinct vmnet interfaces operating in differing modes and a way to selectively map the guests' netdevs to them.

Incidentally, the original problem which has me inclined to hack on QEMU is also network related; I couldn't find an existing way to simulate carrier loss, e.g. were a cable modem to lose power or simply decide to disable its Ethernet interface.

[tamird]

If you just want to use QEMU with vmnet you can run it with sudo.

[c-wicklein]

@tamird Thanks, I needed that reminder! I decided early on that I really didn't want to run QEMU as root, but given the apparent lack of alternatives, I ended up writing an execution wrapper in Bash to inspect QEMU's command line arguments and render a sandbox-exec profile on-the-fly which prevents QEMU from writing to unexpected (by me) places, a typical profile coming out like...

(version 1)
(allow default)
(deny file-write*)
(allow file-write*
    (path "/dev/null")
    (path "/Users/me/Library/Containers/com.utmapp.UTM/Data/Documents/Debian 12.6 Router Peer Devices.utm/Data/973B22E4-B8BD-4CFE-90AB-582F28A54BE5.qcow2")
    (path "/Users/me/Library/Containers/com.utmapp.UTM/Data/Documents/Debian 12.6 Router Peer Devices.utm/Data/efi_vars.fd")
)

[AkihiroSuda]

sandbox-exec seems deprecated according to the man page 😞