This is an old revision of the document!
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
- Project site: http://www.virtualsquare.org/
- Project site: VDE at SF.net
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.
vdetermdocumentation is here
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
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 betag=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