[libvirt] [PATCH] in vbox driver, interface type bridge should really be type ethernet
If I understand correctly, the "bridge" type for an interface means libvirt is in charge of creating a tun device and adding it to the specified bridge in the <source bridge=".."> attribute. This is not what the (badly named IHMO) "Bridged Networking" mode in vbox does: all it does is read and write its packets on the specified interface. Which is what a type "ethernet" interface does in my opinion. I joined a quick patch for that, Pritesh could you check it ? Also, I was about to patch to add support for the proper "bridge" mode in the vbox driver (because it's what I need in the end), but I see no way of storing the fact that it's not just an "ethernet" interface using the vbox API, so that the config would persist over libvirtd restarts. There is always the possibility of naming the interface a special way like "br1_myTap", and assume any type "ethernet" interface with a device containing a "br1_" prefix would actually be a type "bridge" interface with an associated "vbox_br1" bridge. Would that be acceptable, or is it too hackish ? BTW, just to make sure, I can use pretty much anything as a <target> ie. ethN, panN etc in a type "ethernet" interface, right ? If <target> is specified, it's not going to create a tun and use that ? Thanks, Florian
Hi Florian, On Wednesday 30 September 2009 20:08:36 Florian Vichot wrote:
If I understand correctly, the "bridge" type for an interface means libvirt is in charge of creating a tun device and adding it to the specified bridge in the <source bridge=".."> attribute.This is not what the (badly named IHMO) "Bridged Networking" mode in vbox does: all it does is read and write its packets on the specified interface. Which is what a type "ethernet" interface does in my opinion. I joined a quick patch for that, Pritesh could you check it ?
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
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. Thanks, Florian
Could we get some "arbitration" by the powers-that-be ? :) Thanks, Florian Florian Vichot a écrit :
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.
Thanks, Florian
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 06, 2009 at 04:08:25PM +0200, Florian Vichot wrote:
Could we get some "arbitration" by the powers-that-be ? :)
I delegate to Mark or Dan on this semantic of network naming question :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
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 :|
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.
Thank you for taking the time to clarify. Ok now I get it. I would agree, type=bridge is compliant with what it does. What got me confused is I assumed type bridge meant "use of a brctl kinda of bridge" where in libvirt it really means "bridge between the VM and the LAN".
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.
Well I did a version for my app, so my need is taken care of. As I don't think anyone has a need for it apart from me, and that it would take me much longer to do a clean patch for libvirt, I'll probably keep my non-libvirt version (which really is a workaround to some annoying VirtualBox behaviour anyway), and concentrate the little time I can find to work on libvirt on more useful patches :) so I guess you can drop the patch. Thanks again, Florian
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Florian Vichot -
Pritesh Kothari