[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [libvirt] [PATCH] in vbox driver, interface type bridge should really be type ethernet
- From: "Daniel P. Berrange" <berrange redhat com>
- To: Florian Vichot <florian vichot diateam net>
- Cc: libvir-list redhat com, Pritesh Kothari <Pritesh Kothari Sun COM>
- Subject: Re: [libvirt] [PATCH] in vbox driver, interface type bridge should really be type ethernet
- Date: Wed, 7 Oct 2009 21:38:38 +0100
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.
|: 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 :|
[Date Prev][Date Next] [Thread Prev][Thread Next]