Virtualization: Notes to self

This is just things I wrote down while playing with QEMU/KVM virtualization, for my own purposes of packing two existing computers into a third one. There is no point to make here, and neither do I expect anyone to understand this. It’s published because I don’t care to.

Log files

There are definitely two files one wants to peek at every now and then

• /var/log/libvirt/qemu/{guest-name}.log (in particular when a USB device doesn’t attach)
• /var/log/audit/audit.log (SELinux audit, possibly piped to grep -E ‘^type=(AVC|SELINUX\_ERR)’ to reduce amount of junk)

Start with running virt-manager as a non-root user (it will fail with a nondescriptive message if trying to run it as root). A root password will have to be fed.

Use qcow2 disk images

If you’re going to play around with the image, and then maybe want to get rid if the changes, this is sooo simple:

#qemu-img create -F raw -b clean-hda.img -f qcow2 hda.qcow2

Note that qemu-img can also create and apply snapshots of images, which is also good.

Don’t try to use Virtual Machine manager’s clone utility for qcow2 images, since the tool will rewrite all data.

USB device passtrough

It looks like libvirt doesn’t massage the permissions for USB character devices, before adopting them, so both classic permissions and SELinux blow when trying to run passthrough. The current workaround would be to change the USB device’s classic permission manually, and run in permissive mode. Which is indeed unhealthy, but harmless given the fact that XP gives a healthy blue screen in response to the new device. I think I saw XP complaining something about USB 2.0 versus USB 1.1.

Running the same scenario with a knoppix LiveCD image, I managed to find the device (a Canon 500D camera) with lsusb. The root USB hub was shown to be a UHCI. I’m not sure whether a real PTP camera would respond to a UHCI hub, which maybe explains why Windows got confused finding such a camera under the emulated hub.

The emulator appears as /usr/bin/qemu-kvm under the SELinux domain (type) svirt_t, which is decleared in /usr/share/selinux/devel/include/services/virt.if (which you don’t want to read).

USB devices appear somewhere under /dev/bus/usb/ as character devices with SELinux type usb_device_t.

Command line

Create a guest, run it and pause it. Then dump its XML by something like (as root):

# virsh dumpxml try1 > ~eli/virt/try1.xml

Then play around with the XML file a bit, destroy the previous domain, and

# virsh create ~eli/virt/try2.xml

How can I manually manipulate the list of guests?

virsh # start demo
error: Failed to start domain demo
error: internal error unable to start guest: qemu: could not open disk image /home/eli/virt/tryxp.img: Permission denied

Reason(?): tryxp.img is of the wrong context, so SELinux prevents it to be opened…? But I ran SELinux in permissive mode. How could this happen? Or, as put in the Fedora 12 Virtualization Guide:

SELinux prevents guest images from loading if SELinux is enabled and the images are not in the correct directory. SELinux requires that all guest images are stored in /var/lib/libvirt/images.

Basically, what solved this was to move the image to the dedicated directory, and going:

# virt-install --force --name demo3 --ram 1024 --import --disk path=/var/lib/libvirt/images/tryxp.img

or even better:

# virt-install –force –name demo5 –ram 1024 –import –disk path=/var/lib/libvirt/images/hda.img

For playing around:

# virsh

“Stealing” command lines from Virtual Machine Manager

After running a machine under the GUI interface, it’s possible to do so for running on an external VNC console. Just find the command with ps aux | grep qemu-kvm. The following changes in flags apply:

• Remove the -S flag. It says that the guest should not start until commanded to do so.
• Remove the -montitor flag. We’re running on VNC only
• Change the -vnc flag’s address to point to an address known to the outside world, if necessary
• Add “-usbdevice tablet” so that the mouse is followed correctly
• Change the -net flags (two of them) to “-net nic -net user”. This is said to have a performance hit, but it’s simple and it works with an internal (fake) DHCP server

The tip of the day

In the relevant terminology, “source” refers to information seen by the host OS, while “target” to the guest OS.

Another little tip: If I try to install Windows 7, and the installation gets stuck for very long periods of time with nothing really happening, maybe it’s because the disk image is read-only? :-O

VMPlayer

Running VMplayer on a 2.6.35 kernel requires a small fix, which was published here. The thing is that some kernel symbol has changed its name, and hence the vmmon module fails to compile. How I love when people are sensitive about backward compatibility.

To make a long story short, one needs to go to where the VMplayer module sources are, and go:

$ perl -pi -e 's,_range,,' iommu.c

which is bit of a Columbus egg, I would say. Also, VMplayer repeatedly wanted to compile the modules every time I started it, because it missed vsock (which wasn’t compiled in the first place), so I followed the same page‘s hint and edited /etc/vmware/config to say

VSOCK_CONFED = "no"

By the way, I tried to figure out what this module does, and all google results tell you how to tweak and patch. Don’t people care what they do on their computers? Maybe this component is useful?

The following remark was true when this post was published, but no more:

To run VMPlayer under Fedora 12, there’s a need for a little hack, or the VMPlayer closes right after starting:

# cd /usr/lib/vmware/resources/
# mv mozilla-root-certs.crt old-mozilla-root-certs.crt

Have no idea why this is.