On Monday 18 April 2011, Asias He wrote:
> We do need "guest appearing on the same network as the host" support as
> well. The reason I am considering using macvatp instead of tap plus
> brctl is that it simplifies the bridge configuration and it is more
> efficient.
Right, you certainly don't need to consider tap/brctl any more.
> However, IMHO, the interface of macvtap is not user friendly, at least
> for me. I have no idea about the technical reasons that make the
> low-level device inaccessible. But if it is accessible, a lot of
> configuration can be eliminated. I know virtualbox's bridge mode has
> this kind of restriction, while VMware's bridge mode does not.
The main reason is that having a MAC address scan in the regular
networking core would make the common TX case where there is no
macvlan device more complex. Macvtap is derived from the plain
macvlan driver, which used to support only sending out to the
wire until I added the optional bridge mode.
If you want a regular device to be able to send to a macvlan
port, that would require at least these changes:
* Add an option to put a plain device into macvlan-bridge mode
* Add support for that option into iproute2
* Add a hook into dev_queue_xmit() to check for macvlan ports
Arnd
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
