[libvirt] Different mac address used in libvirtd

[Laine Stump]

(slowly working through libvir-list backlog from when I was on vacation...)

On 06/29/2012 11:53 AM, Daniel P. Berrange wrote:
> On Wed, Jun 20, 2012 at 07:01:17PM +0800, Yong Sheng Gong wrote:
>> Hi,
>> I found libvirtd will create vnet0 with a different mac other than the one defined in domain file. The mac in Domain file will be used by qemu-kvm.
>> I want to know how libvirtd decides the mac for vnet0, Who can give me a hint about the location of the libvirtd codes which does this work?
>>
>> I cannot find how the libvirtd translates the mac from one defined in domain file to vnet0's one in src/util/bridge.c: brSetInterfaceMac()
>>     <interface type='bridge'>
>>       <mac address='fa:16:3e:28:64:c2'/>
>>       <source bridge='br100'/>
>>       <target dev='vnet0'/>
>>       <filterref filter='nova-instance-instance-00000002-fa163e2864c2'>
>>         <parameter name='DHCPSERVER' value='10.0.1.1'/>
>>         <parameter name='PROJNET' value='10.0.1.0'/>
>>         <parameter name='PROJMASK' value='255.255.255.0'/>
>>         <parameter name='IP' value='10.0.1.2'/>
>>       </filterref>
>>       <alias name='net0'/>
>>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
>>     </interface>
> The XML mac address config, sets the MAC address for the *guest*
> NIC, ie what the guest uses as its eth0.
>
>
>
>> [root at robinlinux eclipsecdt]# ifconfig  vnet0
>> vnet0     Link encap:Ethernet  HWaddr FE:16:3E:28:64:C2  
>>           inet6 addr: fe80::fc16:3eff:fe28:64c2/64 Scope:Link
>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>           RX packets:553 errors:0 dropped:0 overruns:0 frame:0
>>           TX packets:1485 errors:0 dropped:0 overruns:0 carrier:0
>>           collisions:0 txqueuelen:500 
>>           RX bytes:136360 (133.1 KiB)  TX bytes:280590 (274.0 KiB)
> vnet0 is the backend of the guest NIC, and its MAC addr
> is more or less irrelevant to functioning of the guest
> itself, since traffic does not originate on this NIC.

Actually there is one way that the MAC address of the tap device affects
proper operation of guest networking - if you happen to set the tap
device's MAC identical to the MAC used by the guest, you will get errors
from the kernel similar to this:


  kernel: vnet9: received packet with own address as source address

There was a bug filed about this (someone tried to set their guest's MAC
address to start with 0xFE):

      https://bugzilla.redhat.com/show_bug.cgi?id=798467

and a corresponding check was added to libvirt to prevent it from happening.

> The only important thing is that this TAP device must
> have a high value MAC address, to avoid the bridge
> device using the TAP device's MAC as its own. Hence
> when creating the TAP Device  libvirt takes the guest
> MAC addr and simply sets the top byte to 0xFE
>