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