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).
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
-----
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 qemudBuildComma ndLine if -no-kvm is passed, then deactivate QEMUD_CMD_ FLAG_DRIVE_ BOOT
----------
Here's the patch inline: qemu_conf. c qemu_conf. c ndLine( virConnectPtr conn, VIRT_QEMU) VIRT_QEMU) {
-----
--- a/src/qemu/
+++ b/src/qemu/
@@ -3707,9 +3707,17 @@ int qemudBuildComma
* 2. The qemu binary has the -no-kvm flag
*/
if ((qemuCmdFlags & QEMUD_CMD_FLAG_KVM) &&
- def->virtType == VIR_DOMAIN_
+ def->virtType == VIR_DOMAIN_
disableKVM = 1;
+ /* FLAG_DRIVE_ BOOT) FLAG_DRIVE_ BOOT;
+ * 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_
+ qemuCmdFlags -= QEMUD_CMD_
+ }
+
/* Should explicitly enable KVM if
* 1. Guest domain is 'kvm'
* 2. The qemu binary has the -enable-kvm flag
-----
Drew Daniels