Bug 730753 - support for seamless SPICE migration - botched patch in rhel 6.2 libvirt build
Summary: support for seamless SPICE migration - botched patch in rhel 6.2 libvirt build
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: All
OS: Linux
low
medium
Target Milestone: beta
: ---
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 589989
Blocks: 620748 743047
TreeView+ depends on / blocked
 
Reported: 2011-08-15 16:27 UTC by Eric Blake
Modified: 2011-12-06 11:26 UTC (History)
17 users (show)

Fixed In Version: libvirt-0.9.4-11.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 589989
Environment:
Last Closed: 2011-12-06 11:26:44 UTC


Attachments (Terms of Use)
libvirtd crash log when do spice migration (64.48 KB, text/plain)
2011-09-08 10:37 UTC, weizhang
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1513 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-12-06 01:23:30 UTC

Comment 1 Eric Blake 2011-08-15 16:31:40 UTC
Marking as a regression, in that all 6.y libvirt clients should properly be able to manage all other 6.y servers, but with the botched patch, a 6.2 client cannot migrate with seamless spice to a 6.0 server.

Comment 3 Eric Blake 2011-08-16 12:59:44 UTC
Additional analysis shows that although the patch in isolation is flawed, we _happened_ to get lucky that patch application via 'patch' during rpmbuild picked the correct offset (but in a function different than the context named in the patch) - it was only patch application via 'git am' that was picking the wrong offset (but in the function named in the patch context).  Therefore, libvirt-0.9.4-4.el6 happens to not have any problems, but only by luck, and it is still worth fixing the patch file to make it an offset-free unambiguous patch targeting the correct file name.
http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-August/msg00507.html

Comment 10 weizhang 2011-08-24 02:46:22 UTC
Thanks Eric's detailed explanation 

verify pass on
libvirt-0.9.4-5.el6.x86_64

check the patch of libvirt-0.9.4-5.el6, compare with libvirt-0.9.4-4.el6, the patch name libvirt-Support-seemless-migration-of-SPICE-graphics-clients.patch is changed to libvirt-Support-seamless-migration-of-SPICE-graphics-clients-FIXED.patch, and the patch location is changed from qemuMonitorJSONMigrate to qemuMonitorJSONGraphicsRelocate, and the added contents are same.

Comment 12 Osier Yang 2011-08-24 07:27:23 UTC
Do we support migration between different libvirt versions offcially?

Comment 13 Jiri Denemark 2011-09-07 09:32:11 UTC
Migration to older libvirtd is not supported in general (though it may work if you are lucky enough) since lots of things can break. The new libvirtd may create domain XML that the old one doesn't understand, e.g. It's similar to downgrade, if you create a domain and downgrade libvirtd, we can't support you either.

However, comment 1 seems to be about a bit different scenario. In that case both libvirtd versions match but the client (virsh) is different. You should be able to use virsh from 6.2 to connect to a 6.0 host with libvirtd and manage migration. Although I don't really understand how this could be influenced by the patch fixed in this BZ :-)

Comment 14 Eric Blake 2011-09-08 07:58:11 UTC
The patch fixed by this BZ enables the use of a rhel-specific feature of qemu, as shipped for rhel 6.0.  Upstream qemu learned a more generic seamless graphics migration, and upstream libvirt supports the more generic version as well.  The scenario where this patch comes into play is:

start with a rhel 6.0 machine (qemu only understands the older rhel-specific form of the monitor command)
upgrade libvirt but not qemu to rhel 6.2
perform a migration - the spice transition should still be seamless, because the newer libvirt was able to fall back to the older rhel-specific monitor command

I agree with Jiri's comments that the migration is best done between source and destination both running the same versions of libvirt and qemu.

Comment 15 weizhang 2011-09-08 10:36:24 UTC
(In reply to comment #14)
> The patch fixed by this BZ enables the use of a rhel-specific feature of qemu,
> as shipped for rhel 6.0.  Upstream qemu learned a more generic seamless
> graphics migration, and upstream libvirt supports the more generic version as
> well.  The scenario where this patch comes into play is:
> 
> start with a rhel 6.0 machine (qemu only understands the older rhel-specific
> form of the monitor command)
> upgrade libvirt but not qemu to rhel 6.2
> perform a migration - the spice transition should still be seamless, because
> the newer libvirt was able to fall back to the older rhel-specific monitor
> command
> 

I test with what you said, install 2 hosts with rhel6.0 release and only update libvirt, libvirt-client and libvirt-python to 0.9.4-10, then do spice migration, then libvirtd will crash. May be it is another problem, I am not sure.

# rpm -qa qemu-kvm kernel
qemu-kvm-0.12.1.2-2.113.el6.x86_64
kernel-2.6.32-71.el6.x86_64

> I agree with Jiri's comments that the migration is best done between source and
> destination both running the same versions of libvirt and qemu.

Comment 16 weizhang 2011-09-08 10:37:02 UTC
Created attachment 522088 [details]
libvirtd crash log when do spice migration

Comment 17 Jiri Denemark 2011-09-08 11:48:01 UTC
Heh, thanks for reporting this, it's actually the same BZ since the patch is still not right. When trying RHEL-only __com.redhat_spice_migrate_info command after the upstream one failed, we call qemuMonitorJSONMakeCommand() to prepare it but we do not ever send it to qemu. Also error processing of the upstream command seems not to be exactly right.

Comment 20 weizhang 2011-09-09 02:27:48 UTC
Verify pass on 
libvirt-0.9.4-11.el6.x86_64
working on rhel6.0 release host

seamless spice migration can work well

Comment 21 errata-xmlrpc 2011-12-06 11:26:44 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1513.html


Note You need to log in before you can comment on or make changes to this bug.