[libvirt] Bugfix for RHEL 5.4+ ?? -- Re: Synchronous commands block virsh?
Hi list, I found this thread from December: http://www.mail-archive.com/libvir-list@redhat.com/msg18595.htm .... that starting with version 0.7.4 libvirtd will no longer block other API calls, which would be extremely useful in HA clusters in combination with live migration. Will this fix find its way into RHEL 5? Regards, Andreas
On Mon, Jan 18, 2010 at 01:52:15PM +0100, Andreas Kurz wrote:
Hi list,
I found this thread from December:
http://www.mail-archive.com/libvir-list@redhat.com/msg18595.htm
.... that starting with version 0.7.4 libvirtd will no longer block other API calls, which would be extremely useful in HA clusters in combination with live migration.
Will this fix find its way into RHEL 5?
The fixes for that are *incredibly* invasive & thus have very high risk to stability. So that's not the kind of thing that's likely to be approved for a RHEL5 minor update. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Hi all, Thanks for the information Daniel! On Wednesday 20 January 2010 11:55:41 Daniel P. Berrange wrote:
On Mon, Jan 18, 2010 at 01:52:15PM +0100, Andreas Kurz wrote:
Hi list,
I found this thread from December:
http://www.mail-archive.com/libvir-list@redhat.com/msg18595.htm
.... that starting with version 0.7.4 libvirtd will no longer block other API calls, which would be extremely useful in HA clusters in combination with live migration.
Will this fix find its way into RHEL 5?
The fixes for that are *incredibly* invasive & thus have very high risk to stability. So that's not the kind of thing that's likely to be approved for a RHEL5 minor update.
I tried to compile libvirtd 0.7.5 for RHEL5 to test it in our lab an ran into major troubles when it comes to KVM integration .... do you see a realistic change that such a new Version is compileable on RHEL5 systems? A question to a possible workaround: is it possible to limit the maximum time for a live migration and ... if exceeded ... fall back to "simple" migration? Regards, Andreas
On 01/20/2010 06:18 AM, Andreas Kurz wrote:
Hi all,
Thanks for the information Daniel!
On Wednesday 20 January 2010 11:55:41 Daniel P. Berrange wrote:
On Mon, Jan 18, 2010 at 01:52:15PM +0100, Andreas Kurz wrote:
Hi list,
I found this thread from December:
http://www.mail-archive.com/libvir-list@redhat.com/msg18595.htm
.... that starting with version 0.7.4 libvirtd will no longer block other API calls, which would be extremely useful in HA clusters in combination with live migration.
Will this fix find its way into RHEL 5?
The fixes for that are *incredibly* invasive & thus have very high risk to stability. So that's not the kind of thing that's likely to be approved for a RHEL5 minor update.
I tried to compile libvirtd 0.7.5 for RHEL5 to test it in our lab an ran into major troubles when it comes to KVM integration .... do you see a realistic change that such a new Version is compileable on RHEL5 systems?
Hm, interesting. I just compiled libvirt git head (effectively 0.7.6) on my RHEL-5 box here, and it worked just fine with one minor tweak. The minor tweak I had to make was to make the qemu driver understand that qemu-kvm lives in /usr/libexec. That's the following patch: diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index c227fe1..2ba8366 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -797,7 +797,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 */ + const char *const kvmbins[] = { "/usr/libexec/qemu-kvm", /* RHEL */ + "/usr/bin/qemu-kvm", /* Fedora */ "/usr/bin/kvm" }; /* Upstream .spec */ for (i = 0; i < ARRAY_CARDINALITY(kvmbins); ++i) { If that doesn't fix it for you, what kind of error messages are you getting? -- Chris Lalancette
On Fri, Jan 22, 2010 at 01:11:01PM -0500, Chris Lalancette wrote:
On 01/20/2010 06:18 AM, Andreas Kurz wrote:
Hi all,
Thanks for the information Daniel!
On Wednesday 20 January 2010 11:55:41 Daniel P. Berrange wrote:
On Mon, Jan 18, 2010 at 01:52:15PM +0100, Andreas Kurz wrote:
Hi list,
I found this thread from December:
http://www.mail-archive.com/libvir-list@redhat.com/msg18595.htm
.... that starting with version 0.7.4 libvirtd will no longer block other API calls, which would be extremely useful in HA clusters in combination with live migration.
Will this fix find its way into RHEL 5?
The fixes for that are *incredibly* invasive & thus have very high risk to stability. So that's not the kind of thing that's likely to be approved for a RHEL5 minor update.
I tried to compile libvirtd 0.7.5 for RHEL5 to test it in our lab an ran into major troubles when it comes to KVM integration .... do you see a realistic change that such a new Version is compileable on RHEL5 systems?
Hm, interesting. I just compiled libvirt git head (effectively 0.7.6) on my RHEL-5 box here, and it worked just fine with one minor tweak. The minor tweak I had to make was to make the qemu driver understand that qemu-kvm lives in /usr/libexec. That's the following patch:
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index c227fe1..2ba8366 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -797,7 +797,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 */ + const char *const kvmbins[] = { "/usr/libexec/qemu-kvm", /* RHEL */ + "/usr/bin/qemu-kvm", /* Fedora */ "/usr/bin/kvm" }; /* Upstream .spec */
for (i = 0; i < ARRAY_CARDINALITY(kvmbins); ++i) {
If that doesn't fix it for you, what kind of error messages are you getting?
I think we should push that patch, but I though we were now using $PATH to lookup executable. In any case /usr/libexec/ is not in the default path so this still sounds right, ACK, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (4)
-
Andreas Kurz -
Chris Lalancette -
Daniel P. Berrange -
Daniel Veillard