(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@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