[Bug 284190] Network silently fails after vmotion/suspention when using NetMap on VMware vmx interfaces

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 20 Jan 2025 13:27:50 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284190

            Bug ID: 284190
           Summary: Network silently fails after vmotion/suspention when
                    using NetMap on VMware vmx interfaces
           Product: Base System
           Version: 14.2-STABLE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: alexis.savin@efficientip.com

System's network stack silently fails after a vmotion triggered by the vcenter
(DRS or Host Evacuation) as soon as netmap is used on a VMware vmx interface to
handle the traffic.

Reproducing the issue with a manual vmotion is not guaranteed, however,
suspending the virtual machine then resuming it does trigger the issue. As a
result, the best easiest way to reproduce the issue with the usual system
tools:

1. Deploy a FreeBSD 14.2 Stable (or Release), We will refer to it as the
target.
2. Configure the network on the target with a static IP address (ex:
172.16.42.42).
3. Install the netmap bridge utility on the target
(https://github.com/luigirizzo/netmap/tree/master/apps/bridge).
4. On the target run the following command: 'bridge -i netmap:vmx0'.
5. Deploy or leverage any other device on your network (the source) to ping the
target.
6. On the source, ping the target (172.16.42.42) and observe the latency
(everything is supposed to be fine).
7. Suspend the target from the VMware vcenter or ESX.
8. Resume the target from the VMware vcenter or ESX.
9. Observe that the network does not come back up (no answer to the ping).

Notice: Running netmap in emulated mode does not trigger the same issue. When
sysctl dev.netmap.admode is set to '2', the network does come back as expected.

Note: This is clearly a different issue than #252265 which is clearly fixed
since FreeBSD 13.

-- 
You are receiving this mail because:
You are the assignee for the bug.