[libvirt] [PATCH] Fix executable name and version parsing for KVM 0.11.0-stable.

Nix nix at esperi.org.uk
Mon Nov 30 22:17:25 UTC 2009

 src/qemu/qemu_conf.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

On 30 Nov 2009, Cole Robinson uttered the following:
> If you create a manual bridge, virt-manager should see it. However, the
> virtinst bug I mentioned in my other email was conspiring to make this not
> work for you. Pull from virtinst, and your manually created bridge devices
> should show up in virt-manager.

Pulled. Bridges still show up as 'not bridged', inactive.

I'm giving up. I've spent a week of free time fighting libvirt and
virt-manager and they simply don't seem to be ready for anything but the
simplest of use cases: by comparison I had qemu pretty much working from
the source in about twenty minutes, including reading the manuals from
zero qemu knowledge.

Maybe libvirt works better if you're using one of the subset of popular
distros for which netcf knows how to parse and manipulate the network
config (something which no serious site is going to allow in any case,
because they have their own network control scripts). Maybe libvirt and
virt-manager are only meant to be useful for single-user desktops and
very small sites, in which case it would be nice to, y'know, *say* that
somewhere, perhaps along with a big banner saying "don't bother using
the code from upstream if you're not running unmodified Fedora or RHEL",
so people don't waste their time trying to make it work otherwise. Maybe
I overstate the case, but I don't think by much. I've looked at libvirt
support in a pile of not-completely-mainstream distros now and I haven't
yet found one in which networking works without manual bringup, because
netcf fails to parse the distro config files (yes, I know Augeas support
is possible, but not many people have written that and nobody but Debian
has contributed it upstream: a shame, Augeas is *lovely*). And that then
lands me in the same situation I've just been trying and failing to get
out of.

Whenever anything goes wrong in the virtualization layer I have to fall
back to raw qemu for monitor access in any case, because for reasons
incomprehensible to me libvirt actually bans me from accessing the
monitor or even adding a -serial mon:telnet stanza (or *anything*
user-definable) to the command line: and it insists on using VNC
consoles so I can't use the SDL console's monitor either (though this is
reasonable: you want to be able to stop virt-manager and leave the
emulator running, which VNC makes easier). So the ability to ignore the
nuts and bolts of your virtualization system's command line is
effectively lost the first time anything goes wrong, and you have to
keep everything working without libvirt as well. (Of course the qemu
guys assume you have monitor access when trying to debug problems.)

While I wish I *could* use libvirt (the ability to start VMs as a
regular user with working tun/tap alone would be excellent), it's just
not remotely ready for serious use yet, though it's a very promising
start and has all the infrastructure that it needs to be something very
nice indeed in the future. I think I'll hack up something much simpler
for now which just kicks up tun/tap devices as root and passes their fds
down to setuid() children that run specified qemus as a regular
user. You'd think someone would have written this already...

Have a patch to be going on with, anyway: libvirt can't parse the
version output of qemu-kvm 0.11.0-stable, and doesn't know the name of
its x86_64 upstream binary. (I'm not certain that this is right:
I'm not sure it can distinguish between KMM and non-KVM. I'm equally
unsure that this matters anymore now that enough KVM support to be
getting on with is upstream.)

diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 8f8d490..10efdae 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -642,7 +642,8 @@ qemudCapsInitGuest(virCapsPtr caps,
     if (STREQ(info->arch, hostmachine) ||
         (STREQ(hostmachine, "x86_64") && STREQ(info->arch, "i686"))) {
         const char *const kvmbins[] = { "/usr/bin/qemu-kvm", /* Fedora */
-                                        "/usr/bin/kvm" }; /* Upstream .spec */
+                                        "/usr/bin/kvm", /* Upstream .spec */
+                                        "/usr/bin/qemu-system-x86_64" }; /* Upstream sources */
         for (i = 0; i < ARRAY_CARDINALITY(kvmbins); ++i) {
             if (access(kvmbins[i], X_OK) == 0 &&
@@ -953,6 +954,7 @@ static unsigned int qemudComputeCmdFlags(const char *help,
  * in parenthesis as follows:
  *  - qemu-kvm-x.y.z in stable releases
  *  - kvm-XX for kvm versions up to kvm-85
+ *  - kvm-devel for kvm 0.11.0-stable
  *  - qemu-kvm-devel-XX for kvm version kvm-86 and later
  * For qemu-kvm versions before 0.10.z, we need to detect
@@ -962,6 +964,7 @@ static unsigned int qemudComputeCmdFlags(const char *help,
 #define QEMU_VERSION_STR    "QEMU PC emulator version"
 #define QEMU_KVM_VER_PREFIX "(qemu-kvm-"
+#define KVM_GIT_STABLE_VER_PREFIX  "(kvm-devel)"
 #define KVM_VER_PREFIX      "(kvm-"
 #define SKIP_BLANKS(p) do { while ((*(p) == ' ') || (*(p) == '\t')) (p)++; } while (0)
@@ -1005,6 +1008,9 @@ int qemudParseHelpStr(const char *help,
         *is_kvm = 1;
         p += strlen(QEMU_KVM_VER_PREFIX);
+        *is_kvm = 1;
+        p += strlen(KVM_GIT_STABLE_VER_PREFIX);
     } else if (STRPREFIX(p, KVM_VER_PREFIX)) {
         int ret;

More information about the libvir-list mailing list