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:

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:

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: 

# 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