-
-
Notifications
You must be signed in to change notification settings - Fork 174
Description
Environment:
-
OS: FreeBSD 15.0-RELEASE (Architecture: FreeBSD:15:*) -
vm-bhyve version: 1.7.0_1
The Problem: When creating a virtual switch and attempting to bind it to a pre-existing system bridge (configured in /etc/rc.conf), vm-bhyve ignores the -bridge parameter. Instead of attaching tap interfaces directly to the specified system bridge, it creates a new bridge interface (e.g., vm-public) and isolates the VM traffic there.
This causes connectivity issues when host services (like Samba or Nginx) are bound to the IP address on the primary system bridge, as the VM's tap interface ends up on a separate, unlinked virtual bridge.
Steps to reproduce:
- Create a system bridge in
/etc/rc.conf:
cloned_interfaces="bridge0"
ifconfig_bridge0="inet 192.168.0.2 netmask 255.255.255.0 addm re0 up"
ifconfig_re0="up"
-
Attempt to create a vm-switch linked to this bridge: vm switch create -t standard -bridge bridge0 public
-
Check vm switch list. Often the output shows IFACE: vm-public or even bridge0 but the underlying system.conf is generated with inconsistent naming (e.g., switch_list="bridge0" vs bridge_public="bridge0").
-
Start a VM. The tap interface is not added to bridge0 members.
Expected behavior: The tap interface generated for the VM should be automatically added as a member of the pre-existing bridge0 interface.
Current Workaround: I had to implement a devd rule to force-attach tap interfaces to bridge0 upon creation:
vim /usr/local/etc/devd/vm-tap.conf
notify 100 {
match "system" "IFNET";
match "type" "ATTACH";
match "subsystem" "tap[0-9]+";
action "ifconfig bridge0 addm $subsystem";
};