[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Getting tap networking working

From: Dale R. Worley
Subject: Re: [Qemu-discuss] Getting tap networking working
Date: Wed, 4 Jun 2014 19:22:01 -0400

> From: Vlad Yasevich <address@hidden>

> The problem is that openvpn creates a tun type device which is a
> layer 3 (IP) device, not an layer 2 (ethernet) device.  As such,
> I am really surprised you could even bridge the two.  That should
> have been rejected, as bridge requires ethernet type devices.
> You can create tap devices with
>  ip tuntap add dev tap1 mode tap user worley
> and then bridge them just like you did above.  That will allow things
> to work.

Many thanks for the advice!  I also looked at:


The critical points to getting it working seem to be:

1) Getting the specifications of the back-end (host side) and the
front-end (guest side) of the simulated interfaces connected.  The
symptom of getting this wrong is messages like "Warning: vlan 0 with
no nics" and "Warning: nic eth has no peer".

The main documentation (qemu-doc.html) is very unclear about this, but
the non-deprecated method is:  The back-end is created with a -netdev
option and the front-end is created with a -device option.  The
-device option for an interface contains a "netdev" specification with
the same value as the "id" specification of the corresponding -netdev

2) Using the correct type of device for the back-end interface, "tap"
rather than "tun".  (The interface name is given by the "ifname"
specification of the -netdev option.)

"tap" devices can be created by 'ip' in this manner:
    ip tuntap add dev tap1 mode tap

3) Setting a unique MAC address on the guest side of each VM's
interface.  QEMU provides each virtual NIC with a MAC address (of
course), but it is *not* taken from the MAC address of the tap device
it is connected to.  If you don't specify it, every QEMU instance uses
one default MAC for every guest NIC.  And the packets that go onto the
bridge carry the MAC address of the virtual NIC, not that of the
back-end tap device.  If two VMs use the same MAC address, packets
can't be routed properly by the bridge.

The recommendation is that you give each virtual NIC a unique MAC
address starting with "52:54" (which is a locally-administered MAC

The front-end MAC address is set by the "mac" specification of the
-device option.  (Beware that some documentation mistakenly says this
is the "macaddr" specification!)

4) Some documentation shows IPv4 packet forwarding being set on (by
manipulating /proc/sys/net/ipv4/ip_forward).  This is *not* necessary.

Assembling all of this, the following instructions create a working
network between two VMs:

$ brctl addbr br0
$ brctl setfd br0 0
$ ifconfig br0 up

$ ip tuntap add dev tap1 mode tap
$ brctl addif br0 tap1
$ ifconfig tap1 promisc up

$ ip tuntap add dev tap2 mode tap
$ brctl addif br0 tap2
$ ifconfig tap2 promisc up

$ systemctl stop firewalld

$ qemu-system-i386 -m 1G -machine accel=kvm -enable-kvm -name 'QEMU 1' 
-no-reboot \
        -drive file=linux.system.disk1,media=disk,index=0,snapshot=on \
        -hdb linux.second.disk1 \
        -netdev tap,id=eth,ifname=tap1,script=no,downscript=no \
        -device e1000,netdev=eth,mac=52:54:00:00:00:01 &
$ qemu-system-i386 -m 1G -machine accel=kvm -enable-kvm -name 'QEMU 2' 
-no-reboot \
        -drive file=linux.system.disk1,media=disk,index=0,snapshot=on \
        -hdb linux.second.disk2 \
        -netdev tap,id=eth,ifname=tap2,script=no,downscript=no \
        -device e1000,netdev=eth,mac=52:54:00:00:00:02 &

In VM 1:
$ ifconfig ens3 up
In VM 2:
$ ifconfig ens3 up


reply via email to

[Prev in Thread] Current Thread [Next in Thread]