Hi Florian, On Wednesday 30 September 2009 20:08:36 Florian Vichot wrote: 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. so frankly even thought the patch looks sane I am not sure about the terminology there and am confused as well. Maybe someone with greater knowledge in the networking area of libvirt should comment on it. Regards, Pritesh

Could we get some "arbitration" by the powers-that-be ? :) Thanks, Florian Florian Vichot a écrit :

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