User Tools

Site Tools


linux:generic:qemu

Table of Contents

QEMU

Citation from wiki.qemu.org:

QEMU is a generic and open source machine emulator and virtualizer.

When used as a machine emulator, QEMU can run OSes and programs made
for one machine (e.g. an ARM board) on a different machine (e.g. your own PC).
By using dynamic translation, it achieves very good performance.

When used as a virtualizer, QEMU achieves near native performances by executing
the guest code directly on the host CPU. QEMU supports virtualization when executing
under the Xen hypervisor or using the KVM kernel module in Linux. When using KVM,
QEMU can virtualize x86, server and embedded PowerPC, and S390 guests.

Networking

Quite nice summary of QEMU networking at QEMU wiki. Beware, though, it doesn't describe everything. However, it describes and clarifies QEMU “VLANs” which are usually confused for 802.1q. I originally wanted to describe it here, but since it's described elsewhere, I won't.

VDE2

VDE is an ethernet compliant virtual network that can be spawned over a set of physical
computer over the Internet. VDE is part of virtualsquare project.

I think VDE is fairly simple to setup and use and sufficient for regular use. I haven't tried to connect multiple VDE switches together yet.

Configuration

VDE doesn't require any special configuration for basic networking. However, here is a list of noteworthy things about VDE:

  • QEMU has to be compiled with VDE support, resp. –enable-vde
  • VDE can be configured either via RC script on start up or via vdeterm
  • VDE has to be configured every time it starts up
  • main documentation(?) incl. vdeterm documentation is here
  • you might need tunctllink and socat

To start up VDE switch with Host's tap interface (on port#1) attached and configuration read from rc script:

vde_switch \
-s /var/run/vde2/vde.virswitch0 \
--mgmt /var/run/vde2/vde.virswitch0.sock \
--mgmtmode 660 \
-p /var/run/vde2//vde.virswitch0.pid \
-t virswitch0 \
-f /etc/vde2/vswitches/virswitch0.rc1

As for rc script, you just put the same commands as you would via vdeterm.

Hooking up with QEMU

This fairly simple:

[other QEMU parameters]
-netdev vde,id=hostnet0,sock=PATH_TO_VDE_SOCK
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=RANDOM_VM_MAC,multifunction=on

And if you want to hook up your VM on specific port. This is quite useful when VLANs are used:

[other QEMU parameters]
-netdev vde,id=hostnet0,sock=PATH_TO_VDE_SOCK,port=VDE_PORT_NUM
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=RANDOM_VM_MAC,multifunction=on

VLANs

VLANs with VDE are easy and a bit tricky at the same time. What I really like is they remind me VLANs in non-Cisco hardware - simple, easy, clean.

You can configure VLANs in two ways. Either via vdeterm or via RC script. Actually, I'd say these two go hand in hand where former is good for testing and latter for a “stable” operational state. I'm not going over vdeterm commands here. You can(and should) read documentation by yourself and I see no reason to parrot it here.

Here is a simple and short RC script/set of vdeterm commands:

port/setnumports 32
port/sethub 0

vlan/create 100

port/create 1
port/allocatable 1 0

port/create 2
port/allocatable 2 0
vlan/add 100 2

port/create 3
port/allocatable 3 0
port/setvlan 3 4095
vlan/add 100 3

port/create 4
port/allocatable 4 0
port/setvlan 4 100

And here is explanation(matches commands +/-):

  1. switch has 32 ports
  2. it's a switch, not a hub
  3. create VLAN 100
  4. create port #1 which:
    1. can be allocated only if ',port=1' is passed to QEMU
    2. accepts untagged traffic, resp. traffic with VLAN#0
  5. create port #2 which:
    1. can be allocated only if ',port=2' is passed to QEMU
    2. add port to VLAN#100(must be tagged by the sender)
    3. accepts untagged traffic, resp. traffic with VLAN#0
  6. create port #3 which:
    1. can be allocated only if ',port=3' is passed to QEMU
    2. doesn't accept untagged traffic, resp. traffic with VLAN#0
    3. add port to VLAN#100(must be tagged by the sender)
  7. create port #4 which:
    1. can be allocated only if ',port=4' is passed to QEMU
    2. all incoming untagged traffic is tagged with VLAN#100

Some more notes:

  • how-to delete VLAN#0 or remove ports from VLAN#0
    • you can't, because it's used for untagged traffic
    • however you can 'port/setvlan PORT_NO 4095' to ignore all untagged traffic(as discussed at SF.net VDE mailing list)
    • or 'port/setvlan PORT_NO VLAN_NO' to set default VLAN for untagged traffic
    • NOTE: there is a bug, at least in VDE2-2.3.2, which will cause vde_switch to crash. Bugfix is in SVN.
      1. 'port/setvlan PORT_NO 4095'
      2. attach QEMU VM specifically to 'PORT_NO'
      3. your vde_switch has crashed
  • 'port/allocatable'
    • seems to be thing you want when running VLANs
    • you really don't want your VM to be auto-binded to random port with “unexpected” port settings, eg. incorrect VLAN
  • FIXME connect two VDE switches
    • # dpipe vde_plug /tmp/vde1 = vde_plug /tmp/vde2 & ;
    • however, why would you use # dpipe; since you can use the very same TAP interface?
    • could you use OpenVPN(tap interface)? and wouldn't it be better?
  • FIXME monitoring traffic - I haven't tried it

Open vSwitch

Project site: openvswitch.org

I don't know what-where-how yet. This isn't meant to be a comprehensive how-to anyhow.

Open vSwitch seems to be fairly easy to setup for basic virtual networking, although I can imagine it gets come complicated with OpenFlow and what not. Utilization of tap helps to the easy part. The hard part is rather lack of explanation what-why-how. But I've made it so far, so it can't be that hard :-)

Initialization and start

# just for the first time to initialize DB
ovsdb-tool create /etc/openvswitch/conf.db

# this turns out to be important unless you want to run Open vSwtich in user-space, which I don't want nor know how
modprobe openvswitch

ovs-controller --detach --pidfile punix:/var/run/openvswitch/ovs-controller.sock
ovsdb-server --remote=punix:/var/run/openvswitch/db.sock --pidfile --detach
ovs-vswitchd --detach --pidfile

It's good to omit –detach and run in foreground until you get everything setup and working.

Configuration

I really don't need nor want the basic setup shown all over the intranet. Not for my use anyhow. Oh, btw, br0 gets created auto-magically by ovs-vswitchd.

ovs-vsctl add-br br0

And since I'm not adding eth0, but need to communicate with VMs from the Host and since it doesn't seem like a good idea(?) to give IP address to br0 itself, then:

ovs-vsctl add-port br0 br0-nic -- set interface br0-nic type=internal

In case you need to change port configuration, you don't have to remove it and add it back again. Just do:

ovs-vsctl set port tap0 tag=100
# to verify port settings
ovs-vsctl list port tap0

# display information about switch; similar commands
ovs-ofctl show br0

# ports and their configurations
ovs-vsctl list interface

And that's pretty much it. I find information about switch a bit confusing since it says “current: 10MB-FD COPPER”. Err … right.

As for QEMU ifup/ifdown scripts, they're a bit different than ordinary tap scripts:

# ifup
ovs-vsctl add-port br0 "${1}"
ip link set "${1}" up

# ifdown
ip link set "${1}" down
ovs-vsctl del-port br0 "${1}"

Hooking up with QEMU

Is fairly easy and not different than hooking up tap.

[other QEMU parameters]
-netdev type=tap,id=guest0,script=PATH_TO_UP_SCRIPT,downscript=PATH_TO_UP_SCRIPT 
-device virtio-net-pci,netdev=guest0,mac=RANDOM_VM_MAC

VLANs

Right, the most interesting thing. I only wish somebody haven't decided to use Cisco terminology for VLANs.

Possible values for vlan_mode setting:

  • access - for VM without knowledge of any VLANs; ``An access port can have only one VLAN configured on the interface; it can carry traffic for only one VLAN.“
  • trunk - for connecting switches and routers(?), resp. wherever you need tagged and untagged traffic; ``A trunk port can carry untagged packets simultaneously with the 802.1Q tagged packets.”
  • native-tagged - seems to allow only tagged packets(tagged on VM), untagged traffic seems to be dropped; equivalent seems to be tag=VLAN_ID (?)
  • native-untagged - all untagged traffic is tagged as VLAN ID X on the switch, tagged VLANs(tagged on VM) are passed on
# untagged VLAN 100; these two commands are equivalent
ovs-ctl add-port br0 tap0 tag=100
ovs-vsctl set port tap0 tag=100
ovs-vsctl set port tap1 tag=100 vlan_mode=native-untagged

# tagged VLAN 100
ovs-vsctl set port tap1 tag=100 vlan_mode=native-tagged

# tagged VLAN 100 and 200
ovs-ctl add-port br0 tap1 trunk=100,200

# multiple tagged VLANs(tagging done on VM), default VLAN for untagged traffic is 100
ovs-ctl set port tap1 tag=100 vlan_mode=native-untagged
linux/generic/qemu.txt · Last modified: 2013/06/08 09:20 by stybla