Bridged networking does not recover after unplugging and reconnecting the Ethernet Cable

[LuoXiaoyi]

Environment

• VirtualBuddy version: [2.1(325)]
• Host macOS version/build: [26.5 (25F71)]
• Host Mac model/chip: [Apple M2 Pro]
• Guest OS version/build: [26.5 (25F71)]
• Physical Ethernet adapter: [Thunderbolt adapter]
• Bridged interface setting: [explicitly selected interface]
• VPN enabled: [Yes]
• Network environment: [managed enterprise switch]

Problem description

I am experiencing a reproducible bridged-networking problem when running a virtual
machine in VirtualBuddy.

The bridged network works normally when the VM is initially started. The guest obtains
a valid IP address from the LAN DHCP server and can access the local network.

However, if I unplug the host’s physical Ethernet cable, leave it disconnected for some
time, and then reconnect it, the host network recovers but the VM network does not.

The guest can no longer obtain a DHCP lease. Renewing DHCP inside the guest does not
resolve the problem. It eventually assigns itself a link-local address in the following
range:

169.254.240.x

Once this happens, the guest appears unable to recover the previous LAN address, or
obtain any valid DHCP address, even though the host Ethernet connection is working
normally again.

Steps to reproduce

1. Configure the VM to use bridged networking over the host’s physical Ethernet
   interface.
2. Start the VM.
3. Confirm that the guest receives a valid LAN address through DHCP.
4. Unplug the physical Ethernet cable from the host.
5. Wait for some time.
6. Reconnect the Ethernet cable.
7. Confirm that the host Mac regains normal Ethernet connectivity.
8. Renew DHCP inside the guest.

For a macOS guest, I tried renewing DHCP using the network settings and commands
similar to:

sudo ipconfig set en0 NONE
sudo ipconfig set en0 DHCP

Actual behavior

• The host Ethernet network recovers normally.
• The VM remains disconnected.
• DHCP renewal inside the guest does not work.
• The guest eventually receives a self-assigned 169.254.x.x address.
• Restarting the DHCP client inside the guest does not restore connectivity.
• A normal guest reboot may also be insufficient if VirtualBuddy keeps the same running
  VZVirtualMachine instance and network attachment.

Expected behavior

After the host Ethernet link becomes active again, VirtualBuddy should reconnect the
bridged network attachment automatically.

The guest should then be able to send DHCP Discover packets to the physical network and
obtain a valid DHCP lease without requiring VirtualBuddy or the VM to be completely
restarted.

Suspected cause

My current hypothesis is that the host-side VZBridgedNetworkDeviceAttachment is
disconnected when the physical Ethernet link goes down and is not recreated after the
link comes back.

Apple’s documentation states that the attachment of a running VZNetworkDevice may
change at any time depending on the host network state:

• VZNetworkDevice.attachment
  (https://developer.apple.com/documentation/virtualization/vznetworkdevice/attachment)

• attachmentWasDisconnectedWithError

  (https://developer.apple.com/documentation/virtualization/vzvirtualmachinedelegate/virtualmachine%28_%3Anetworkdevice%3Aattachmentwasdisconnectedwitherror%3A%29)

According to the documentation, when an attachment fails, Virtualization.framework may
set networkDevice.attachment to nil and notify the application through:

virtualMachine(
_:networkDevice:attachmentWasDisconnectedWithError:
)

VirtualBuddy currently implements this delegate method, but its body is empty:

public nonisolated func virtualMachine(
_ virtualMachine: VZVirtualMachine,
networkDevice: VZNetworkDevice,
attachmentWasDisconnectedWithError error: Error
) {

}

Source:

• VMInstance.swift, lines 508–510

  (

  VirtualBuddy/VirtualCore/Source/Virtualization/VMInstance.swift

  Lines 508 to 510 in 943b3c0

  	public nonisolated func virtualMachine(_ virtualMachine: VZVirtualMachine, networkDevice: VZNetworkDevice, attachmentWasDisconnectedWithError error: Error) {
  	}

  )

If the cable disconnection causes this callback to be invoked, the network attachment
may remain nil because VirtualBuddy does not currently log the error or attempt to
reconnect it.

This would explain why DHCP renewal inside the guest cannot work: the guest network
interface still exists, but DHCP broadcasts can no longer reach the host’s physical
network.

Additional observation about “Automatic” bridging

VirtualBuddy appears to resolve the “Automatic” bridge interface only when creating the
VM configuration. It selects the first available bridged interface:

guard identifier != VBNetworkDeviceInterface.automatic.id else {
return try VZBridgedNetworkInterface.networkInterfaces.first.require(...)
}

Source:

• VirtualMachineConfigurationHelper.swift, lines 140–159

  (

  VirtualBuddy/VirtualCore/Source/Virtualization/Helpers/VirtualMachineConfigurationHelper.swift

  Lines 140 to 159 in 943b3c0

  	private var vzAttachment: VZNetworkDeviceAttachment {
  	get throws {
  	switch kind {
  	case .NAT:
  	return VZNATNetworkDeviceAttachment()
  	case .bridge:
  	let interface = try resolveBridge(with: id)
  	return VZBridgedNetworkDeviceAttachment(interface: interface)
  	}
  	}
  	}
  	private func resolveBridge(with identifier: String) throws -> VZBridgedNetworkInterface {
  	guard identifier != VBNetworkDeviceInterface.automatic.id else {
  	return try VZBridgedNetworkInterface.networkInterfaces.first.require("There are no network interfaces available on the host for bridging.")
  	}
  	return try VZBridgedNetworkInterface.networkInterfaces.first(where: { $0.identifier == identifier })
  	.require("The bridged network interface \(identifier.quoted) is not available.")
  	}

  )

This does not appear to provide dynamic failover or re-evaluation when the physical
network changes. For example, if Ethernet goes down and Wi-Fi becomes the default
route, the existing bridge attachment may remain associated with the unavailable
Ethernet interface.

Possible ways to confirm the cause

DHCP and ARP traffic can be captured simultaneously in the guest and on the host.

Inside the guest:

sudo tcpdump -eni en0 '(udp port 67 or 68) or arp'

On the host’s physical Ethernet interface:

sudo tcpdump -eni enX '(udp port 67 or 68) or arp'

Possible interpretations:

• DHCP Discover is visible in the guest but not on the host Ethernet interface: the
  VirtualBuddy/Virtualization.framework bridge attachment is probably disconnected.

• DHCP Discover reaches the host interface, but no DHCP Offer is returned: the problem
  may be in the router, switch, DHCP server, port security, DHCP snooping, or MAC-
  address policy.

• The host receives a DHCP Offer, but the guest does not: the return path through the
  bridge or a host network filter may be broken.

• No DHCP Discover is generated inside the guest: the problem is more likely in the
  guest network service or virtual NIC state.

It may also help if VirtualBuddy logs the attachmentWasDisconnectedWithError error and
the value of networkDevice.attachment before and after the physical link interruption.

Suggested workarounds

The following workarounds may help:

1. Completely shut down the VM instead of only rebooting the guest.
2. Quit VirtualBuddy completely.
3. Reconnect Ethernet and confirm that the host has a valid IP address.
4. Reopen VirtualBuddy and cold-boot the VM so that a new bridged attachment is
   created.

Possible application-level fix

A possible VirtualBuddy fix would be to:

1. Log the error received through attachmentWasDisconnectedWithError.
2. Detect when the selected host interface becomes available again.
3. Resolve a fresh VZBridgedNetworkInterface using the stored interface identifier.
4. Create a new VZBridgedNetworkDeviceAttachment.
5. Assign it to the running VZNetworkDevice.attachment.
6. Retry with a controlled delay if the physical interface is not ready yet.
7. Optionally provide a “Reconnect Network” action in the VM UI.

Conceptually:

let interfaces = VZBridgedNetworkInterface.networkInterfaces

guard let interface = interfaces.first(where: {
$0.identifier == configuredInterfaceIdentifier
}) else {
// Wait for the interface to become available and retry.
return
}

let newAttachment = VZBridgedNetworkDeviceAttachment(
interface: interface
)

networkDevice.attachment = newAttachment

The reconnection should use a newly resolved interface object instead of reusing the
attachment or interface object that existed before the physical link went down.

Could you confirm whether this behavior is expected from Virtualization.framework, and
whether VirtualBuddy is expected to recreate the bridge attachment after receiving
attachmentWasDisconnectedWithError?

[insidegui]

Fix implemented in #717, will be out in the next beta