Can't boot qemu w/o kvm (no boot=on param, upstream patch)

Thanks for taking the time to submit this bug.

However, if I understand right, lucid's qemu *does* support 'boot=on' since it is qemu-kvm. The libvirt source has changed a great deal since the version in lucid, and would need to be re-written. Finally, as lucid is LTS, I'd be afraid of doing this in a way that would change behavior for some existing users.

Please feel free to attach a patch and rationale that there is no chance of regression (to change my or someone else mind), but given that this is for use with a non-standard qemu, I'm going to mark this wontfix.

Is there something in particular you need from that version of qemu? If there's a bug perhaps we can fix that in the qemu-kvm package?

It should also be possible for you to use a backport of maverick's libvirt to natty.

Hi,
I'm willing to rebuild and test the fix myself when I get some time, but I thought it might be faster and easier for a maintainer to do.

I apologise if this comment seems negative, it's not intended as such.

1) lucid's qemu does not seem to support boot=on, but maybe my testing is wrong? Certainly libvirt's upstream says that not all versions of qemu do even though the documentation may say that it does. I can get ReactOS to boot without this parameter, but I can't get it to boot with this parameter. I isolated the commands to that one difference.

2) qemu-kvm does not require kvm. Many peices of hardware, including mine don't support kvm. Perhaps this is what's misleading you.

3) I did attach a patch from upstream. I figured attaching a patch would make it easier to spot rather than having to see that there's a link to a patch in the git repository. It looks like the patch doesn't effect qemu when in kvm mode, and it looks like lucid's qemu without kvm doesn't support boot=on (but perhaps my testing is flawed? See point 1).

4) I'm using lucid. Is maverick's libvirt already in a supported backported archive? I don't see it, but I do see a bug that says it's not there: https://bugs.launchpad.net/lucid-backports/+bug/724026

5) I've added the tags "patch" and "patch-accepted-upstream". I hope that's appropriate.

Here's the metadata about the patch:
----- cut -----
author Daniel Veillard <email address hidden>
  Fri, 30 Jul 2010 14:38:48 +0000 (16:38 +0200)
committer Daniel Veillard <email address hidden>
  Fri, 30 Jul 2010 14:38:48 +0000 (16:38 +0200)

  Basically the 'boot=on' boot selection device is something present in KVM but not in upstream QEmu, as a result if we boot a QEmu domain without KVM acceleration we must disable boot=on ... even if the front end kvm binary expose that capability in the help page.

* src/qemu/qemu_conf.c: in qemudBuildCommandLine if -no-kvm is passed, then deactivate QEMUD_CMD_FLAG_DRIVE_BOOT
----------

Here's the patch inline:
-----
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -3707,9 +3707,17 @@ int qemudBuildCommandLine(virConnectPtr conn,
      * 2. The qemu binary has the -no-kvm flag
      */
     if ((qemuCmdFlags & QEMUD_CMD_FLAG_KVM) &&
- def->virtType == VIR_DOMAIN_VIRT_QEMU)
+ def->virtType == VIR_DOMAIN_VIRT_QEMU) {
         disableKVM = 1;

+ /*
+ * do not use boot=on for drives when not using KVM since this
+ * is not supported at all in upstream QEmu.
+ */
+ if (qemuCmdFlags & QEMUD_CMD_FLAG_DRIVE_BOOT)
+ qemuCmdFlags -= QEMUD_CMD_FLAG_DRIVE_BOOT;
+ }
+
     /* Should explicitly enable KVM if
      * 1. Guest domain is 'kvm'
      * 2. The qemu binary has the -enable-kvm flag
-----

     Drew Daniels