I think I’m done playing with Libvirt for the moment.  As a general purpose library management tool it looks good.  From an ease-of-use perspective I suspect its not bad if you are running in an X-windows environment.  From a “lets convert” standpoint?  Well, that is proving to be another issue.

For instance, I currently start up my KVMs with a command similar to:

kvm -net nic,model=virtio -net tap,ifname=tap6,script=no  -drive file=test2.img,if=virtio,boot=on -curses -no-reboot -m 2g -smp 2

This starts a fully paravirtualized instance using virtio for both networking and the disk image.  The resulting VM has 2gb of memory and 2 virtual CPUs allocated to it.

Libvirt uses XML files to control everything, an idea I fully support.  However getting started creating those can be a challenge.  I found two approaches.  The first was with a related tool called “virt-install”.  It is not part of the libvirt, but built using it and closely tied to it.  So after playing for a bit, I came up with:

virt-install –name “test2” –ram 2048 –vcpus=2  –cpu host –description “Test VM” –import –file test2.img –os-type=linux –os-variant=virtio26  –network bridge=br0,model=virtio –graphics=none   –noreboot

Using the virsh list command shows the VM has been created and is running!  Probing around a bit shows the file /etc/libvirt/qemu/test2.xml has been created.  Using virsh edit test2 puts me into a VI editing session on the XML.  All looks good.  Now to connect.  Connect?  Connect to what?  I try opening a ssh session and it times out.  Unlike when I issue the KVM command directly, there is no associated curses window to look it.  Looking at /var/log/libvirt/qemu shows a log of the command being issued… very useful!  Apparently a serial console connection has been opened on /dev/pts/2.  Ok, crank up screen /dev/pts/2 and it connects, but there is no output…  Looking at the log file shows a few concerning things:  1) KVM is being started up with a “-S” switch, which the developers tell me is normal, but the man-pages say disables the startup of the CPUs.  Its sure behaving like the man-pages are right.  2) the image file is being started with “if=none” instead of “if=virtio”.  A bit of command line testing verifies that “if=none” prevents the kernel from finding the root disk.  Not good.  Checked in with the user-list community and the generated XML looks appropriate, so this issue remains pending.  Finally, the network is not being started using tap6, my assigned network device for this VM.

The user community suggested I try an alternative method to generate the initial XML.  Apparently virsh amoungst its MANY options, has one for generating XML from a command line!  Cool.  Wish I had noticed that earlier.  The command:

virsh domxml-from-native qemu-argv /kvms/test2 >test2.xml

Takes the file test (which contains the KVM command at the top of this post) and converts it to equivalent xml for libvirt.  Very Cool!  Well, at least in concept.  It has a few very minor parsing problems, like the “2g” for memory must be specified as “2048” (in megabytes).  Also the kvm command must be fully qualified as /usr/bin/kvm.  Other than that, its works fine.  The generated xml looks very similar to that created by virt-install with a few minor differences like the instance not being named (ok, ok, its named “unnamed”) and the OS architecture and CPU information is generic X86 instead of the very specific AMD statements generated by virt-install.  There is also no serial port defined like virt-install did, but there is a “ethernet” device now that reflects my tap6 port.  A bit of cut & pasting and I managed to create a custom.xml with the best of both worlds.  Issuing virsh define /kvms/custom.xml imports the new xml file and again defines and tries to starts a running instance.

Notice the “tries” word above?  The network won’t start, so the instance is stopped.  The network won’t start because the “tap” device apparently needs to be a “tun” device.  Again looking at the log file shows the same if=none for the disk image as well.  Even if I reconfigured my network to use “tun” devices instead of “tap” devices, the VM would not get past booting the kernel.

I’ve spent a significant amount of time browsing the various man pages to try and figure out the above issues.  I did discover that libvirt appears to be more “cutting edge” than even the man pages for kvm.  e.g.  It uses some “newer” format parameters that I couldn’t find in the man pages (both local and on the official qemu site), which was a bit frustrating, but the format was pretty obvious. It also appears that the libvirt world really is built around VMs being behind a NAT subnet which libvirt wants to control.  It may be possible to get around that, but so far I haven’t had any luck.

So, for now, I’ll just manage my VMs from the command line, and start them via /etc/local.d/local.start.