---
/* We need to set the interface MAC before adding it
* to the bridge, because the bridge assumes the lowest
* MAC of all enslaved interfaces & we don't want it
* seeing the kernel allocate random MAC for the TAP
* device before we set our static MAC.
*/
virMacAddrSet(&tapmac, macaddr); if (!(flags &
VIR_NETDEV_TAP_CREATE_USE_MAC_FOR_BRIDGE)) {
/* The tap device's MAC address cannot match the MAC address
* used by the guest. This results in "received packet on
* vnetX with own address as source address" error logs from
* the kernel. Making the tap address as high as possible
* discourages the bridge from using this tap's MAC as its own
* (a Linux host bridge will take on the lowest numbered MAC
* of all devices attached to it).
*/
if (tapmac.addr[0] =3D=3D 0xFE)
tapmac.addr[0] =3D 0xFA;
else
tapmac.addr[0] =3D 0xFE;
} if (virNetDevSetMAC(*ifname, &tapmac) < 0)
goto error;
---
Could you help confirm the exact behavior in this case? Specifically:
1. If a target tap device already exists, does libvirt modify the MAC
address instead of recreating the device?
2. Under what circumstances does libvirt destroy and recreate the tap
device instead of modifying its attributes?
Looking forward to your insights!
Best regards,
Xuda Zhang
Laine Stump <laine@xxxxxxxxx> =E4=BA=8E2025=E5=B9=B42=E6=9C=884=E6=97=A5=E5=
=91=A8=E4=BA=8C 02:34=E5=86=99=E9=81=93=EF=BC=9A
> (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 MA=
C
> >> 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 co=
de
> >> 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,
>
>
--0000000000009bb8bc062d5d393f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D""><p style=3D"font-f=
amily:arial,helvetica,sans-serif">Dear [Libvirt Developer Team],</p><p styl=
e=3D"font-family:arial,helvetica,sans-serif">It has been quite some time si=
nce I initially sent my email, and I never expected to receive a response a=
fter so long.=C2=A0</p><p style=3D"font-family:arial,helvetica,sans-serif">=
I sincerely appreciate your time and effort in addressing this case =E2=80=
=94 thank you!</p><p style=3D"font-family:arial,helvetica,sans-serif">Regar=
ding your question:</p><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 gue=
st (VM)?</blockquote><p style=3D"font-family:arial,helvetica,sans-serif">Ye=
s, that is precisely what I meant!</p><p style=3D"font-family:arial,helveti=
ca,sans-serif">Now, returning to the issue at hand: the distinctiveness of =
MAC addresses is a fundamental principle of network communication.</p><p st=
yle=3D"font-family:arial,helvetica,sans-serif">This issue was originally ra=
ised by a friend of mine. While I was able to explain the theoretical impor=
tance of unique MAC addresses, I couldn't provide a clear explanation o=
f how libvirt handles the "automatic modification" of the tap dev=
ice's MAC address, as I had only observed changes in the device's s=
tate but not the modification itself in the logs.</p><p style=3D"font-famil=
y:arial,helvetica,sans-serif">After carefully reviewing your response multi=
ple times and conducting additional tests, I now fully understand the mecha=
nism behind the "0xFE" modification of the first byte of the MAC =
address, which is handled in <code>virNetDevTapCreateInBridgePort()</code> =
at line 638 (starting at line 625).</p><p style=3D"font-family:arial,helvet=
ica,sans-serif">However, I wanted to confirm one specific point regarding t=
ap device behavior. According to the <a rel=3D"noopener" href=3D"https://li=
bvirt.org/formatdomain.html#generic-ethernet-connection">official documenta=
tion</a>:</p><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"If no =
target dev is specified, libvirt will create a new standard tap device with=
a name of the pattern 'vnetN', where 'N' is replaced with =
a number. If a target dev is specified and that device doesn't exist, t=
hen a new standard tap device will be created with the exact dev name given=
."</blockquote><p style=3D"font-family:arial,helvetica,sans-serif">In =
contrast, you mentioned:</p><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">"Any time you stop/destroy a guest, any tap device(s) associated wi=
th that guest will be destroyed, and the next time you start the guest, new=
tap devices will be created."</blockquote><p style=3D"font-family:ari=
al,helvetica,sans-serif">From this, it seems that if the tap device already=
exists, the MAC address modification would be a direct "modification&=
quot; rather than a "recreation" of the device. Looking at the co=
de section:</p><pre class=3D"gmail-!overflow-visible" style=3D"font-family:=
arial,helvetica,sans-serif"><div class=3D"gmail-contain-inline-size gmail-r=
ounded-md gmail-border-[0.5px] gmail-border-token-border-medium gmail-relat=
ive gmail-bg-token-sidebar-surface-primary gmail-dark:bg-gray-950"><div cla=
ss=3D"gmail-flex gmail-items-center gmail-text-token-text-secondary gmail-p=
x-4 gmail-py-2 gmail-text-xs gmail-font-sans gmail-justify-between gmail-ro=
unded-t-md gmail-h-9 gmail-bg-token-sidebar-surface-primary gmail-dark:bg-t=
oken-main-surface-secondary gmail-select-none">---</div><div class=3D"gmail=
-overflow-y-auto gmail-p-4" dir=3D"ltr"><code class=3D"gmail-!whitespace-pr=
e gmail-language-c"><span class=3D"gmail-hljs-comment">/* We need to set th=
e interface MAC before adding it =20
* to the bridge, because the bridge assumes the lowest =20
* MAC of all enslaved interfaces & we don't want it =20
* seeing the kernel allocate random MAC for the TAP =20
* device before we set our static MAC. =20
*/</span> =20
virMacAddrSet(&tapmac, macaddr); =20
<span class=3D"gmail-hljs-keyword">if</span> (!(flags & VIR_NETDEV_TAP_=
CREATE_USE_MAC_FOR_BRIDGE)) { =20
<span class=3D"gmail-hljs-comment">/* The tap device's MAC address =
cannot match the MAC address =20
* used by the guest. This results in "received packet on =20
* vnetX with own address as source address" error logs from =20
* the kernel. Making the tap address as high as possible =20
* discourages the bridge from using this tap's MAC as its own =20
* (a Linux host bridge will take on the lowest numbered MAC =20
* of all devices attached to it). =20
*/</span> =20
<span class=3D"gmail-hljs-keyword">if</span> (tapmac.addr[<span class=
=3D"gmail-hljs-number">0</span>] =3D=3D <span class=3D"gmail-hljs-number">0=
xFE</span>) =20
tapmac.addr[<span class=3D"gmail-hljs-number">0</span>] =3D <span c=
lass=3D"gmail-hljs-number">0xFA</span>; =20
<span class=3D"gmail-hljs-keyword">else</span> =20
tapmac.addr[<span class=3D"gmail-hljs-number">0</span>] =3D <span c=
lass=3D"gmail-hljs-number">0xFE</span>; =20
} =20
<span class=3D"gmail-hljs-keyword">if</span> (virNetDevSetMAC(*ifname, &=
;tapmac) < <span class=3D"gmail-hljs-number">0</span>) =20
<span class=3D"gmail-hljs-keyword">goto</span> error;
</code></div><div class=3D"gmail-overflow-y-auto gmail-p-4" dir=3D"ltr"><co=
de class=3D"gmail-!whitespace-pre gmail-language-c">---</code></div></div><=
/pre><p style=3D"font-family:arial,helvetica,sans-serif">Could you help con=
firm the exact behavior in this case? Specifically:</p><ol style=3D"font-fa=
mily:arial,helvetica,sans-serif"><li>If a target tap device already exists,=
does libvirt modify the MAC address instead of recreating the device?</li>=
<li>Under what circumstances does libvirt destroy and recreate the tap devi=
ce instead of modifying its attributes?</li></ol><p style=3D"font-family:ar=
ial,helvetica,sans-serif">Looking forward to your insights!</p><p style=3D"=
font-family:arial,helvetica,sans-serif">Best regards,<br>Xuda Zhang</p></di=
v></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"lt=
r" class=3D"gmail_attr">Laine Stump <<a href=3D"mailto:laine@xxxxxxxxx";>=
laine@xxxxxxxxx</a>> =E4=BA=8E2025=E5=B9=B42=E6=9C=884=E6=97=A5=E5=91=A8=
=E4=BA=8C 02:34=E5=86=99=E9=81=93=EF=BC=9A<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">(Somehow I never received the original of this m=
essage into my libvirt <br>
folder. Possibly my email client mistakenly decided it was spam...)<br>
<br>
On 2/3/25 8:36 AM, Martin Kletzander wrote:<br>
> On Tue, Dec 24, 2024 at 05:26:29PM +0800, Xuda Zhang wrote:<br>
>> Dear Team,<br>
>><br>
> <br>
> Hi, not sure if this is still relevant, but ...<br>
> <br>
>> I am reaching out regarding an issue I encountered with libvirt an=
d MAC<br>
>> address conflicts. Below is a summary of the situation:<br>
>><br>
>> =C2=A0 1. Initially, the vNIC's MAC address was different from=
the target VM's<br>
>> =C2=A0 MAC address.<br>
> <br>
> you are talking about a vNIC from the host's point of view and &qu=
ot;target<br>
> VM" as seen from the guest?=C2=A0 I'm just trying to make sur=
e I understand.<br>
<br>
To further clarify - when you say "vNIC" do you mean the tap devi=
ce that <br>
is connected to the bridge on the host side, and "target VM's MAC =
<br>
address" is the MAC address of the network device inside the guest (VM=
)?<br>
<br>
Assuming that is the case, the explanation is this: The tap device on <br>
the host *must* have a different MAC address than the device in the guest.<=
br>
<br>
If the two MAC addresses are the same, then when the host's network <br=
>
stack see a packet destined for that MAC address, it will think to <br>
itself "Hey - that's the MAC address of an interface on *this* mac=
hine*, <br>
so I don't need to forward it anywhere!" and then attempt to deliv=
er the <br>
packet locally (i.e. send it up to IP on the host). You would of course <br=
>
see this as "guest networking doesn't work".<br>
<br>
The reason that you see the tap device MAC address go back to "normal&=
quot; <br>
when you stop and restart the guest is because any time you stop/destroy <b=
r>
a guest, any tap device(s) associated with that guest will be destroyed, <b=
r>
and the next time you start the guest, *new* tap devices will be <br>
created. And whenever libvirt creates a tap device, it automatically <br>
makes a MAC address that is just "guest interface MAC address, except =
<br>
replace the first byte with 0xFE". This is done to guarantee that the =
<br>
tap device and guest interface have different MAC addresses, but they <br>
are similar to help make it more obvious which tap device is used by <br>
which guest interface (because the MACs are *almost* the same).<br>
<br>
So everything that you see is normal and, for the most part, necessary.<br>
<br>
I'm surprised that you care about the MAC address of the tap device. It=
<br>
really doesn't matter what it is except that it must be different from =
<br>
the MAC in the guest.<br>
<br>
> <br>
>> =C2=A0 2. After modifying the vNIC's MAC address to match the =
VM's MAC <br>
>> address,<br>
>> =C2=A0 the network was interrupted.<br>
>> =C2=A0 3. After rebooting the VM, the vNIC's MAC address was a=
utomatically<br>
>> =C2=A0 modified again.<br>
>><br>
> <br>
> Are you using some filtering (nwfilter) on the libvirt network?<br>
> <br>
>> I have observed the following kernel logs during this process:<br>
>><br>
>> Dec 24 16:59:40 zstack-manager kernel: br_enp2s0: port 14(vnic43.0=
)<br>
>> entered disabled stateDec 24 16:59:40 zstack-manager kernel: devic=
e<br>
>> vnic43.0 left promiscuous modeDec 24 16:59:40 zstack-manager kerne=
l:<br>
>> br_enp2s0: port 14(vnic43.0) entered disabled stateDec 24 17:00:11=
<br>
>> zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered blocki=
ng<br>
>> stateDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port<br>
>> 14(vnic43.0) entered disabled stateDec 24 17:00:11 zstack-manager<=
br>
>> kernel: device vnic43.0 entered promiscuous modeDec 24 17:00:11<br=
>
>> zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered blocki=
ng<br>
>> stateDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port<br>
>> 14(vnic43.0) entered forwarding state<br>
>><br>
>> I am looking to understand the underlying code that handles the au=
tomatic<br>
>> modification of the vNIC's MAC address after the conflict and =
how the<br>
>> network interruption occurs. Can you help direct me to the relevan=
t code<br>
>> segment or provide any insights into this behavior?<br>
<br>
See above for the explanation of why the MAC address of the tap is <br>
changed, and why networking stops if you change it to match the guest <br>
MAC. The code that sets the MAC address is in <br>
virNetDevTapCreateInBridgePort(), src/util/virnetdevtap.c:638 in current <b=
r>
upstream sources - this is done unconditionally every time a tap device <br=
>
is created.<br>
<br>
<br>
>><br>
> <br>
> What conflict are you talking precisely?=C2=A0 Is something having the=
same<br>
> MAC address as the VM?<br>
> <br>
>> Thank you for your assistance.<br>
>><br>
>> Best regards,<br>
<br>
</blockquote></div>
--0000000000009bb8bc062d5d393f--
