Skip to content

feat(vmm): add netd-managed macvtap networking - #1061

Draft
kvinwang wants to merge 7 commits into
nextfrom
feat/vmm-macvtap-netd
Draft

feat(vmm): add netd-managed macvtap networking#1061
kvinwang wants to merge 7 commits into
nextfrom
feat/vmm-macvtap-netd

Conversation

@kvinwang

@kvinwang kvinwang commented Aug 17, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • add first-class macvtap networking to manifests and the VMM RPC
  • extend netd with a dedicated macvtap prepare RPC that creates deterministic interfaces, discovers runtime device nodes, and owns cleanup and rollback
  • pass macvtap devices to QEMU through the per-VM launcher without persisting runtime device paths
  • exec single-process launches in place so Supervisor tracks QEMU directly; retain orchestration when swtpm is present
  • support Supervisor, systemd, one-shot QEMU launches, and swtpm-backed VMs without requiring systemd OpenFile
  • remove the unused cvm.user and sudo QEMU launch setting
  • document configuration, lifecycle, and limitations

This is an alternative to #1047. Device paths are runtime results from netd rather than persistent manifest inputs, so interface identity and lifecycle stay inside dstack and ifindex reuse cannot silently redirect a VM to a stale path.

The existing bridge prepare RPC is renamed independently in #1064.

Design

A macvtap NIC is configured with a parent interface and forwarding mode. The VMM and QEMU use the same deterministic guest MAC. Netd derives the stable interface name, replaces stale state, creates the macvtap, reads its ifindex, waits for the character device, and returns the path for this launch only.

The launcher opens each device, reserves collision-free source fds, and maps them to the QEMU target fds. For a single-process launch it execs QEMU in place; with swtpm it keeps the parent and child orchestration path.

Validation

  • cargo clippy for dstack-vmm with all targets and warnings denied
  • cargo test for dstack-vmm: 120 passed

Not yet tested

  • real-host macvtap creation and udev timing under load
  • end-to-end guest DHCP and connectivity on a physical network that accepts multiple MAC addresses

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant