====== QEMU ======

Citation from [[http://wiki.qemu.org/Main_Page|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 [[http://wiki.qemu.org/Documentation/Networking|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: [[https://sourceforge.net/projects/vde/|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. ''vdeterm'' documentation is [[http://wiki.virtualsquare.org/wiki/index.php/VDE|here]]
  * you might need ''tunctl''[[https://sourceforge.net/projects/tunctl/|link]] and ''socat''

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

<code>
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
</code>

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


=== Hooking up with QEMU ===

This fairly simple:

<code>
[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
</code>

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

<code>
[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
</code>


=== 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:

<code>
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
</code>

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

  - switch has 32 ports
  - it's a switch, not a hub
  - create VLAN 100
  - create port #1 which:
    - can be allocated only if ',port=1' is passed to QEMU
    - accepts untagged traffic, resp. traffic with VLAN#0
  - create port #2 which:
    - can be allocated only if ',port=2' is passed to QEMU
    - add port to VLAN#100(must be tagged by the sender)
    - accepts untagged traffic, resp. traffic with VLAN#0
  - create port #3 which:
    - can be allocated only if ',port=3' is passed to QEMU
    - doesn't accept untagged traffic, resp. traffic with VLAN#0
    - add port to VLAN#100(must be tagged by the sender)
  - create port #4 which:
    - can be allocated only if ',port=4' is passed to QEMU
    - 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 [[https://sourceforge.net/mailarchive/message.php?msg_id=30585925|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.
      - 'port/setvlan PORT_NO 4095'
      - attach QEMU VM specifically to 'PORT_NO'
      - 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 [[http://wiki.virtualsquare.org/wiki/index.php/VDE_Basic_Networking#2._Monitor_traffic|monitoring traffic]] - I haven't tried it


==== Open vSwitch ====

Project site: [[http://www.openvswitch.org|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 ===

<code>
# 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
</code>

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''.

<code>
ovs-vsctl add-br br0
</code>

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:

<code>
ovs-vsctl add-port br0 br0-nic -- set interface br0-nic type=internal
</code>

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

<code>
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
</code>

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:

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

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


=== Hooking up with QEMU ===

Is fairly easy and not different than hooking up ''tap''.

<code>
[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
</code>

=== 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

<code>
# 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
</code>

===== Links =====

  * [[http://openvswitch.org/support/config-cookbooks/vlan-configuration-cookbook/|Open vSwitch VLAN Cookbook]]
  * [[http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=FAQ;hb=HEAD|Open vSwitch FAQ - up-to-date version]]
  * [[http://blog.scottlowe.org/2012/10/04/some-insight-into-open-vswitch-configuration/]]
  * [[http://wiki.virtualsquare.org/wiki/index.php/Main_Page]]
  * [[http://backreference.org/2010/03/26/tuntap-interface-tutorial/]]
  * [[http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge]]
  * [[http://doc.opensuse.org/products/draft/SLES/SLES-kvm_sd_draft/cha.qemu.running.html]]
  * [[http://www.inetdoc.net/travaux_pratiques/interco.ospf.q/interco.ospf.vm.html]]