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