While I started writing init scripts for qemu I’ve been prodded again by Luca to look at libvirt instead of reinventing the wheel. You probably remember me ranting about the whole libvirt and virt-manager suite quite some time ago as it really wasn’t my cup of tea. But then I gave it another try.
*On a very puny note here, what’s up with the lib- prefix here? libvirt, libguestfs, they don’t look even remotely like libraries to me… sure there is a libvirt library in libvirt, but then shouldn’t the daemon be called simply virtd?*
The first problem I found is that the ebuild still tries to force dnsmasq and iptables on me if I have the network USE flags enabled; turns out that neither is mandatory so I have to ask Doug to either drop them or add another USE flag for them since I’m sure they are pain in the ass for other people beside me. I know quite a bit of people ranted about dnsmasq in particular.
Sidestepped that problem I first tried, again, to use the virt-manager graphical interface to build a new VM interface. My target this time was to try re-installing OpenSUSE, this time, though, using the virtio disk interface.
A word of note about qemu vs. qemu-kvm: at first I was definitely upset by the fact that the two cannot be present on the same system, this is particularly nasty considering the fact that it takes a little longer to get the qemu-kvm code bumped when a new qemu is released. On the other hand, after finding out that, yeah, qemu allows you to use virtio for disk device but no, it doesn’t allow you to boot from them, I decided that upstream is simply going crazy. Reimar maybe you should send your patches directly to qemu-kvm, they would probably be considered I guess.
The result of the wizard was definitely not good; the main problem was that the selection for the already-present hard disk image silently failed; I had to input the LVM path myself, which at the time felt a minor problem (although another strange thing was that it could see just one out of the two volume groups I have in the system); but the result was … definitely not what I was looking for.
First problem was that the selection dialog that I thought was not working was working alright… just on the wrong field, so it replaced the path to the ISO image to use for installing with that of the disk again (which as you might guess does not work that well). The second problem was that even though I set explicitly that I wanted to use a Linux version with support for virtio devices, it didn’t configure it to use virtio at all.
Okay, time to edit the configuration file by hand; I could certainly use virt-manager to replace vinagre to access the VNC connections (over unix path instead of TCP/IP to localhost), so that would be enough to me. Unfortunately the configuration file declares it to be XML; if you know me you know I’m not one of those guys who just go away screaming as soon as XML is involved, even though I dislike it as a configuration file it makes probably quite a bit of sense in this case, I found by myself trying to make the init script above usable that the configuration for qemu is quite complex. The big bad turn down for me is that *it’s not XML, it’s aXML (almost XML)!
With the name aXML I call all those uses of XML that are barely using the syntax but not the features. In this particular case, the whole configuration file, while documented for humans, is lacking an XML declaration as well as any kind of doctype or namespace that would tell a software like, say, nxml, what the heck is it dealing with. And more to the point, I could find no Relax-NG or other kind of schema for the configuration file; with one of those, I could make it possible for Emacs to become a powerful configuration file editor: it would know how to validate the syntax and allow completion of elements. Lacking it, it’s quite a task for the human to look at.
Just to make things harder, the configuration file, which, I understand, has to represent very complex parameters that the qemu command line accepts, is not really simplified at all. For instance, if you configure a disk, you have to choose the type between block and file (which is normal operation even for things like iSCSI); unfortunately to configure the path the device or file is found you don’t simply have a <source>somepath</source> element but you need to provide <source dev="/path" /> or <source file="/path" /> — yes, you have to change the attribute name depending on the type you have chosen! And no, virsh does not help you by telling you that you had an invalid attribute or left one empty; you have to guess by looking at the logs. It doesn’t even tell you that the path to the ISO image you gave is wrong.
But okay, after reconfiguring the XML file so that the path is correct, that network card and disks are to use virtio and all that stuff, as soon as you start you can see a nice -no-kvm in the qemu command line. What’s that? Simple: virt-manager didn’t notice that my qemu is really qemu-kvm. Change the configuration to use kvm and surprise surprise: libvirtd crashes! Okay to be fair it’s qemu that crashes first and libvirtd follows it, but the whole point is that if qemu is the hypervisor, libvirtd should be the supervisor and not crash if the hypervisor it launched doesn’t seem to work.
And it goes even funnier: if I launch as root the same qemu command, it starts up properly, without network but properly. Way to go libvirt; way to go. Sigh.
This should fix the problem regarding the image selection dialog (ok, the whole UI is still quite inconsistent, but this works at least in 0.8.1):http://bugs.gentoo.org/show…
Oh, and by the way: you’re absolutely right! ‘aXML’ sucks, it’s like claiming you’re able to speak a foreign language but you just pretend it by babbling words which sound like the language 😉
Actually qemu can boot from a virtio disk. For some reason the -boot option doesn’t work but if you do it like this -drive file=image.qcow2,if=virtio,boot=onit works just fine.
@marios qemu-0.10.1, *not qemu-kvm* does not support the @boot=on@ parameter. Only qemu-kvm supports it.
As for your comment on how qemu and qemu-kvm can’t coexist, maybe the Debian packages help you with that. The qemu-kvm tools on Debian have been renamed:qemu-kvm -> kvmqemu-img -> kvm-imgThey can coexist without any problems.
Used to be that way in Gentoo, they dropped it because upstream does not make that difference and it created more work for the developers, which they didn’t want to deal with.
Dr. Strangelove the qemu-kvm package provides the very same thing qemu does, it just uses the kvm provided patches over vanilla qemu.(so you overall just switch to the newest of the two depending on which one is less broken during in that time)
If you want to discuss XML feature, welcometo the libvirt list. There is of course a Relax-NGschemas and even a validation command line tool.They are both part of the source distribution, ifit doesn’t show up in your distro well it’s *not*libvirt fault !Note however that flaming in a blog is well useless,and if you really want to express your agumentscome on the list, but be prepared, especially for”aXML” be ready for a good beating, I’m also on the XML standard group at W3C and the mainauthor of libxml2, I would have no troubles debunkingyour argument very quickly … Enjoy the safety of your blog >:->Daniel Veillard
Daniel, there is no reference about the Relax-NG schema on the “libvirt format documentation”:http://libvirt.org/format.html is there? Do I have to hunt it down to get it? Is there any reference to the format in the virt-manager generated files? Glad to know the schema exists, I’m definitely going to make it easier to edit those files with emacs in Gentoo then.Beside, that’s definitely the least of my problems with libvirt. The fact that a crash of qemu (which happens with qemu-kvm-0.11.0, and is fixed with 0.11.1) crashes libvirt is *definitely* a problem.And I started the blog saying that it *was* a rant; and as such it doesn’t even pretend to solve anything. If I am to solve something I don’t rant, but I was quite pissed off after virt-manager created a totally fucked up file, and I don’t think there is anything to discuss regarding most of my beefs for the format: while I still think that it’s stupid to have a different attribute depending on whether you’re using a file or a block device to provide the path, changing that would be just stupid.
And just to note, how the heck is one supposed to understand that libvirt’s files are libvirt’s? Because they have no namespace, no document type, no special extension…If you don’t call aXML that…
Want to debunk me? Sure go on…<typo:code>flame@yamato schemas % pwd/home/flame/mytmpfs/libvirt-0.7.4/docs/schemasflame@yamato schemas % xmllint secret.rng secret.rng:41: parser error : Opening and ending tag mismatch: ref line 39 and choice </choice> ^secret.rng:42: parser error : Opening and ending tag mismatch: choice line 38 and element </element> ^secret.rng:43: parser error : Opening and ending tag mismatch: element line 37 and optional </optional> ^secret.rng:44: parser error : Opening and ending tag mismatch: optional line 36 and interleave </interleave> ^secret.rng:45: parser error : Opening and ending tag mismatch: interleave line 25 and element </element> ^secret.rng:46: parser error : Opening and ending tag mismatch: element line 8 and define </define> ^secret.rng:74: parser error : Opening and ending tag mismatch: define line 7 and grammar</grammar> ^secret.rng:75: parser error : Premature end of data in tag grammar line 2^</typo:code>Uh, isn’t @xmllint@ your own code?<typo:code>flame@yamato schemas % qfile `which xmllint` dev-libs/libxml2 (/usr/bin/xmllint)</typo:code>Yup definitely looks like it is…
On the point about “lib” prefixes:libvirt was originally just a library, in fact a kind of replacement for the Xen userspace library and tools which were GPLd (not LGPLd) and couldn’t be linked to proprietary code. Now libvirt is still a C API, but it comes with a lot of other stuff too, including libvirtd which is the all-round management daemon. And of course support goes way beyond just Xen so both the library and daemon component contain a huge amount of code.libguestfs on the other hand really is just a “C library”:http://libguestfs.org/guest…