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.

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

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.

Do we support migration between different libvirt versions offcially?

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 :-)

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.

(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.

Created attachment 522088 [details]
libvirtd crash log when do spice migration

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.

Back in POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-September/msg00293.html

Verify pass on 
libvirt-0.9.4-11.el6.x86_64
working on rhel6.0 release host

seamless spice migration can work well

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