[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] in vbox driver, interface type bridge should really be type ethernet

Hey Pritesh,

> If you check http://libvirt.org/formatdomain.html#elementsNICS then it is not 
> much clear if the type bridged is more suitable or ethernet cause the bridged 
> section says: "This assumes there is a bridge device on the host which has one 
> or more of the hosts physical NICs enslaved" and which is what vbox is doing 
> if i have got the interpretation right.

Well, IIRC, it's not quite what vbox is doing. What libvirt provides
with the bridge mode is this:

                   VM <-> tun <-> bridge

with the bridge designated by the <source bridge=''> and the tun
designated either automatically by libvirt using a vnetN format, or by
the user using <target dev=''>. That way, one can start a second domain,
with the same <source bridge=''> and either specify <target dev=''> or
let libvirt automatically create another tun, and have it added to the
bridge, allowing communication through the bridge with the first domain
as if they where connected through a hardware switch.

What vbox does in the other hand in its oddly named "Bridged networking"
mode is simply this:

                    VM <-> interface

with the VM acting as if it's connected to the interface (which can be
anything) through some kernel module magic. But no bridge is created,
used or even necessary. So I believe type "ethernet" is more suited.
Mostly for semantic reason really, because in this mode, there is no use
for the <target dev=''>; and <source bridge=''> is misleading, as the
value of the "bridge" attribute does not need to be a bridge.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]