Docunext

UPDATE

These notes have been succeeded by QEMU vde Notes Revisited

Note to self

To restart setup like you had before, use these commands:

1. vde_switch -tap qtap0 -daemon
2. vdeqemu -m 1024 -boot c -net nic -net vde -vnc 1 -k en-us deb4vde.raw (can use qemu when bridging - first edit /etc/qemu-ifup (see qemu bridging specifics below) then try qemu -m 96 -vnc :1 -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=/etc/qemu-ifup deb4vde.raw)
3. sudo dnsmasq --log-queries --user=nobody --dhcp-leasefile=/var/tmp/dnsmasq-leasefile --dhcp-range=10.111.111.129,10.111.111.199,255.255.255.0,10.111.111.255,8h --interface=qtap0 --domain=qemu.lan - (not needed when bridging)

You'll also have to get vde_switch, br0 (aptitude install bridge-utils) kqemu going again. Follow notes below.

Now back to QEMU Networking Notes

vde:

vde_switch is the command to use to setup the virtual switch. It will get plugged into the tap0 interface.

dnsmasq:

you probably only want this running on the tap0 interface

qemu:

use vdeqemu wrapper instead.

kqemu:

mknod /dev/kqemu c 250 0

chmod 666 /dev/kqemu

Not so surprisingly, qemu works pretty darn well even over wan links (768k) with nomachine's freenx. I have my setup configured like this:

• Host machine - serving freenx and qemu
• LAN
• m0n0wall VPN router
• INTERNET
• m0n0wall VPN router w/ wireless
• Mac OS X nomachine client running xfce terminal and launching qemu from within it. Loads a "MacOSX" window with QEMU inside of it.

This setup works better than the qemu vnc, as that server doesn't have much when it comes to compression (no tightVNC).

AWESOME! I got it to work with vde. There were a few gotchas:

• Couldn't run qemu or vdeqemu as root or via sudo, the boot would freeze around nic / hd detection.
• To run vdeqemu as normal user, I had to allow access to vde.ctl as described here, but using /tmp/vde.ctl as target on ubuntu:

sudo chmod -R a+rwx /tmp/vde.ctl

• I mainly used the Ubuntu docs for KVM (which also covers qemu and vde)
• Similar to the superuser boot freezes, I experienced issues when trying to use other networking options, including vlans and the realtek virtual card.

I built as small a debian installation as I could. It is based on Debian etch, uses a 300MB raw hard drive (for rough compatibility with Parallels), and no swap. The base install uses about 250MB of memory so there isn't much room left over for other stuff, but if you need more room you can always use an nfs export or something.

As the slackware docs put it, this is a "serious networking powerhouse".

Bridging with QEMU

Now I'm trying to figure out how bridging works. I just took my little dectop down by creating a bridge, then adding the only ethernet interface to it. Must be a problem with the USB ethernet stick (or I brought the network interface down accidentally).

After a cold hard reboot, I added the bridging configuration to /etc/network/interfaces and rebooted again. I first forgot to add "auto br0" so I added that and here's what it finally looks like:

auto br0
iface br0 inet dhcp
        bridge_ports eth0
        bridge_maxwait 2
        #kvm has to have this set to 0.0.0.0 to work... not sure why
        #not sure if promisc is necessary
        up /sbin/ifconfig eth0 inet 0.0.0.0
#set to something random, br0 initialization will undo this
iface eth0 inet static
        address 172.16.5.0
        netmask 255.255.255.0

Amazingly, it works! Now this machine is the little dectop running debian, so I'm a little wary about running QEMU / KQEMU on it, but what the heck - I did just increase the RAM to 256MB, and the hard drive to 80GB! A 300MB QEMU file shouldn't be too much to handle.

qemu -m 96 -vnc :1 -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=/etc/qemu-ifup deb4vde.raw