(Somehow I never received the original of this message into my libvirt
folder. Possibly my email client mistakenly decided it was spam...)
On 2/3/25 8:36 AM, Martin Kletzander wrote:
On Tue, Dec 24, 2024 at 05:26:29PM +0800, Xuda Zhang wrote:
Dear Team,
Hi, not sure if this is still relevant, but ...
I am reaching out regarding an issue I encountered with libvirt and MAC
address conflicts. Below is a summary of the situation:
1. Initially, the vNIC's MAC address was different from the target VM's
MAC address.
you are talking about a vNIC from the host's point of view and "target
VM" as seen from the guest? I'm just trying to make sure I understand.
To further clarify - when you say "vNIC" do you mean the tap device that
is connected to the bridge on the host side, and "target VM's MAC
address" is the MAC address of the network device inside the guest (VM)?
Assuming that is the case, the explanation is this: The tap device on
the host *must* have a different MAC address than the device in the guest.
If the two MAC addresses are the same, then when the host's network
stack see a packet destined for that MAC address, it will think to
itself "Hey - that's the MAC address of an interface on *this* machine*,
so I don't need to forward it anywhere!" and then attempt to deliver the
packet locally (i.e. send it up to IP on the host). You would of course
see this as "guest networking doesn't work".
The reason that you see the tap device MAC address go back to "normal"
when you stop and restart the guest is because any time you stop/destroy
a guest, any tap device(s) associated with that guest will be destroyed,
and the next time you start the guest, *new* tap devices will be
created. And whenever libvirt creates a tap device, it automatically
makes a MAC address that is just "guest interface MAC address, except
replace the first byte with 0xFE". This is done to guarantee that the
tap device and guest interface have different MAC addresses, but they
are similar to help make it more obvious which tap device is used by
which guest interface (because the MACs are *almost* the same).
So everything that you see is normal and, for the most part, necessary.
I'm surprised that you care about the MAC address of the tap device. It
really doesn't matter what it is except that it must be different from
the MAC in the guest.
2. After modifying the vNIC's MAC address to match the VM's MAC
address,
the network was interrupted.
3. After rebooting the VM, the vNIC's MAC address was automatically
modified again.
Are you using some filtering (nwfilter) on the libvirt network?
I have observed the following kernel logs during this process:
Dec 24 16:59:40 zstack-manager kernel: br_enp2s0: port 14(vnic43.0)
entered disabled stateDec 24 16:59:40 zstack-manager kernel: device
vnic43.0 left promiscuous modeDec 24 16:59:40 zstack-manager kernel:
br_enp2s0: port 14(vnic43.0) entered disabled stateDec 24 17:00:11
zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered blocking
stateDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port
14(vnic43.0) entered disabled stateDec 24 17:00:11 zstack-manager
kernel: device vnic43.0 entered promiscuous modeDec 24 17:00:11
zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered blocking
stateDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port
14(vnic43.0) entered forwarding state
I am looking to understand the underlying code that handles the automatic
modification of the vNIC's MAC address after the conflict and how the
network interruption occurs. Can you help direct me to the relevant code
segment or provide any insights into this behavior?
See above for the explanation of why the MAC address of the tap is
changed, and why networking stops if you change it to match the guest
MAC. The code that sets the MAC address is in
virNetDevTapCreateInBridgePort(), src/util/virnetdevtap.c:638 in current
upstream sources - this is done unconditionally every time a tap device
is created.
What conflict are you talking precisely? Is something having the same
MAC address as the VM?
Thank you for your assistance.
Best regards,
