I neeed to move some VMs from a Virtualbox test system to a KVM production host. Hosts are two copies of the very same hardware and software system (64-bit Ubuntu Server v16.04, for what it matters).

It's all not too complex, but the networking part.

For virtualbox' guests I have a single virtio ethernet adapter bridged to one of the host bond devices. The guest is easily accessible from both the network to which the host is attached to and from the host itself. In this way, the guest is like "just another server on the network". During operations I cannot see anything else but the virbr0 bridge.

AFAIU, this simple setup cannot be replicated under KVM. If I use bridging, then I cannot communicate from guest to host. The suggested solution is to add a second interface to the guest for such a use.

Is that the only option I have?

Then, if any technical details is available, I'd like to know how can Virtualbox do something that KVM cannot do.

4 Answers 4


What you describe is an absolutely standard KVM bridged configuration documented pretty much anywhere you care to look. The idea is to have the bond on the host under a bridge (the bridge gets to hold the host's IP config, not the bond), and the VM will be able to use the bridge exactly like you are used to in vbox.

Once you have a bridge available on the host, virt-manager will allow you to choose a shared network device to connect to (e.g. the new bridge), or you can simply update the domxml for the guest to use the bridge and not the default NAT network

  • Would the guest be able to talk also to the host?
    – EnzoR
    Dec 8, 2016 at 16:30
  • @Enzo Of course. There is no question here. Dec 8, 2016 at 16:37
  • of course, they will be on the same L2 network. Plenty of links like this one in google: help.ubuntu.com/community/KVM/Networking#bridgednetworking Two things though: 1) if you're using a wireless NIC, forget about bridging. 2) if you're using bonded interfaces, do not use bonding mode 0 and 6, they are incompatible with bridging
    – dyasny
    Dec 8, 2016 at 16:37

It's been not as easy as expected. The general hint by @dyasny is true: it's doable, indeed. The main objectives here are:

  1. Do not use 3rd party tools (like virsh,virtinst or libvirt) in order to learn and understand.

  2. Run VMs without being root with the normal administration unprivileged user.

Here's how I did it.

  1. Disable the main host interface in /etc/network/interfaces by commenting out the line(s) for the main ethernet.

  2. Create a network bridge containing that interface in the same file. The original interface will loose the IP that will go to the bridge. The configuration file would look like this:

    auto eth0 # no iface and IP stuff
    auto br0
    iface br0 inet static
        bridge_ports    eth0
        bridge_stp      off
        bridge_maxwait  0
        bridge_fd       0
  1. Create an ACL for QEMU to allow the traffic to the bridge in /etc/quemu/bridge.conf, ownership to root:kvm end permissions 0640. The directory /etc/quemu/ needs to be root:kvm and 0770:

sudo mkdir -v /etc/qemu
# 'br0' is the same name as used in the previous step
echo allow br0 | sudo tee -a /etc/quemu/bridge.conf > /dev/null
sudo chown -R -vc root:kvm /etc/qemu
sudo chmod -vc 0770 /etc/qemu
sudo chmod -vc 0640 /etc/qemu/*
  1. Fix the bridge helper script. This is truly mandatory as the default installation if effective only with root.

sudo chmod -vc u+s /usr/lib/qemu/qemu-bridge-helper
  1. Add your unprivileged user to group kvm. You will need to logout and login (or open a new session) in order to make this effective.

sudo usermod -a -G kvm `id -un`
  1. Restart the networking.

sudo service networking restart
  1. Now, when you'll start your VM by command line, you can use for the network device a list of arguments like this:

... \
-netdev bridge,id=net0,br=br0

where net0 is the enumerated network device (the 1st one in this case) and br0 is the name of the bridge interface as defined earlier. So, for example, an example full command line can be this one:

kvm -cpu host -machine q35 -boot order=dc -vga virtio -vnc -name qemutest,process=qemutest -uuid 901f83ce-b999-459b-b1b6-a9ba94cac382 -smp cpus=4 -m size=8192 -cdrom /home/user/image.iso -drive file=/home/user/Desktop/QEMU/qemutest/qemutest-D0.qcow2,if=virtio -device virtio-net-pci,mac=02:19:3e:39:a5:de,netdev=net0 -netdev bridge,id=net0,br=br0
  • You are right, this is absolutely not documented everywhere as was stated in the other answer. It's very hard to find. Apr 4 at 14:58

I also spent several days for the answer, still not fully understand so can't explain the technical detail, but seems like the way virtualbox (host bridge) did doesn't has good performance compares to macvtap.

An evidence:



You could use iptables to nat the internal guests IPs with your public one(s), and then use internal IPs to connect to the guests from the KVM host

  • But that wuld be NAT. I am wishing to reproduce Virtualbox solution with a single bridged interface.
    – EnzoR
    Dec 8, 2016 at 16:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .