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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list