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

[Daniel P. Berrange]

On Fri, Oct 02, 2009 at 12:37:30PM +0200, Florian Vichot wrote:
> 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.

I don't think there's a particularly easy answer here, since there are a
few ways to look at it.	From a POV of 'what does it do', the type=bridge
mode implements a layer-2 (ie ethernet) bridge between the guest and
the LAN.  From a POV of	'how is it done', the type=bridge network mode
could be considered to be a bridge device, with	a NIC backend (of some
type) enslaved.	For QEMU we enslave TAP	devices. Xen enslaves its custom
device.	LXC enslaves veth devices.

The type=ethernet mode in libvirt has pretty ill/un-defined semantics, it
may or may not be doing ethernet layer bridging, though the name strongly
implies	it. There is certainly no requirement that a bridge device be
involved, and the actual setup process is really hypervisor defined with
no rules. With Xen, the type=ethernet mode, could in fact be doing a
layer-3 bridge (IP layer) with proxy_arp.


As you point out, if there is no bridge	device,	or TAP device like thing
involved, then type=bridge has no info available to put in the <target>
and <source> elements. 	I don't	think this particularly	matters	for the
<target> element, since	that's always been pretty optional & not really
critical for the process. For the <source> element I think its nice that
most of	our impls use that as the bridge device	name, though you could
certainly make a reasonable argument that the physical NIC name	would be
applicable here	too if no Linux	type bridge device were	involved. I have
a feeling that Xen on Solaris does this, since I don't think they have a
Linux style bridge involved. I believe VMWare's bridging mode works in
a similar way to Virtualbox, ie not using Linux bridges/tap devs, doing
it natively inside the kernel.

So back to your original question - is the current VirtualBox bridge
impl 'correct'. If it is doing ethernet layer bridging, then I think
there is a strong argument that it is reasonably compliant. If there
is a way todo  bridging with VirtualBox + a bridge + TAP device (or 
equivalent), then that would definitely want to use type=bridge.

Thus the main question is whether to allow both modes to use type=bridge,
or to change the existing mode to use type=ethernet. If we did the former,
then one option is to add an extra attribute to the <source> device so
you can indicate whether the source is a real bridge device, or a NIC
with bridging done by magic inside the kernel.

I think I'd have a slight preference for the latter, since I like the fact
that type=bridge is explicitly about layer-2 bridging, while type=ethernet
is pretty much a generic catch-all, do-anything network mode.

It is probably best if you just go ahead and implement your idea for doing
Virtualbox bridging with a real bridge + tap device, while we consider the
XML modelling problem in parallel.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|