[libvirt] why mac are different between inside and outside of vm

Laine Stump laine at laine.org
Mon Feb 10 09:19:31 UTC 2014


On 02/08/2014 05:46 AM, yue wrote:
> hi, all
> nwfilter has many rules which depends on mac of vm, but i find  the
> mac address inside vm is different from mac outside of vm.
> outside mac:
> vnet0 Link encap:Ethernet HWaddr FE:54:00:71:15:7B ,
> inside mac:
> eth0 Link encap:Ethernet HWaddr 52:54:00:71:15:7B ,virtio 
>  
> why?

The two ends of a tap interface ((1) vnet0 on the host side, and (2) the
backend which connects via the qemu process to eth0 on the guest) *must*
have different MAC addresses, otherwise, it would be impossible to know
whether to forward a packet with that MAC address across the tap, or
deliver it on the local side.  If you want to see the result of making
both sides of a tap interface the same MAC address, just modify the
piece of code in libvirt that replaces the 1st MAC byte with 0xFE and
try starting up a guest - you will see an entry in the system log
complaining about the duplicated MAC address (I don't remember the exact
wording as it's been so long since I saw it).


>  i am afraid that  nwfilter use the wrong one.   

Why do you say that?

> how nwfilter chooses mac? and what is the usage of vnet0's mac?

Packet's destined for that MAC address are delivered to the host via
vnet0, and *if* you gave an IP address to vnet0, that would be the mac
address returned from an ARP request from vnet0's IP address, and
packets with that IP address would be delivered to the host via vnet0.

However, for qemu's use of tap interfaces, the host side of the tap
doesn't have an IP address, so the tap interface's MAC isn't used for
anything. Mainly, it is something that has to be there, but needs to
keep out of the way; the simple way to do that in an orderly fashion is
to replace the first byte of the guest's mac address with 0xFE, just to
be sure there isn't a clash with the guest's MAC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140210/67de6a23/attachment-0001.htm>


More information about the libvir-list mailing list