On 02/08/2014 05:46 AM, yue wrote:
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).
Why do you say that?
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. |
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list