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