Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider one vmnet interface per VM, datagram-based interface #77

Open
tamird opened this issue Nov 18, 2024 · 4 comments
Open

consider one vmnet interface per VM, datagram-based interface #77

tamird opened this issue Nov 18, 2024 · 4 comments
Labels
enhancement New feature or request kind/performance

Comments

@tamird
Copy link

tamird commented Nov 18, 2024

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
Copy link

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
Copy link
Author

tamird commented Dec 3, 2024

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

@c-wicklein
Copy link

@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
Copy link
Member

sandbox-exec seems deprecated according to the man page 😞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request kind/performance
Projects
None yet
Development

No branches or pull requests

4 participants