Comment 3 for bug 921838

I think this might need to be reverted (yes, I know this is all my fault - sorry!)

I'm trying to use FlatManager, and it simply doesn't work once this code is applied.

I was getting errors like this in dmesg:
[ 2199.836114] br100: received packet on vnet1 with own address as source address

I could ping the guest from the host, but the guest couldn't ping out, because ARP resolution inside the guest was failing. I could see the ARP request being made succesfully from the host, but the ARP table wasn't updated in the guest and it would rapidly retry ARP resolution.

I couldn't ping the guest from other machines, I think because the guest didn't know where to send the return packets.

Reverting the change above fixes the problem immediately.

However, something very odd is happening; I think maybe libvirt is doing something we're not aware of that is breaking us: the MAC address of the vnetX interface is 0xfe, though the internal address is 0x02. It looks like when the two are the same things are FUBAR.

I have below 3 machines, the first two launched with the 0xfe and broken, the last one launched with the patch reverted and working.

(The MAC in the host (vnet2) is the same as the guest, but with 0x02 -> 0xfe)
Host: ifconfig
...
vnet0 Link encap:Ethernet HWaddr fe:16:3e:09:66:f7
          inet6 addr: fe80::fc16:3eff:fe09:66f7/64 Scope:Link
...
vnet1 Link encap:Ethernet HWaddr fe:16:3e:14:e1:62
          inet6 addr: fe80::fc16:3eff:fe14:e162/64 Scope:Link
...
vnet2 Link encap:Ethernet HWaddr fe:16:3e:31:8e:88
          inet6 addr: fe80::fc16:3eff:fe31:8e88/64 Scope:Link
...

(The MAC in the guest is the same as vnet2, but with 0x02)
Guest: ifconfig
eth0 Link encap:Ethernet HWaddr 02:16:3e:31:8e:88
...