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 :|