On 03/11/2012 08:16 AM, Yonit Halperin wrote:
Hi,
We would like to implement seamless migration for Spice, i.e., keeping the
currently opened spice client session valid after migration.
Today, the spice client establishes the connection to the destination before
migration starts, and when migration completes, the client's session is moved to
the destination, but all the session data is being reset.
We face 2 main challenges when coming to implement seamless migration:
(1) Spice client must establish the connection to the destination before the
spice password expires. However, during migration, qemu main loop is not
processed, and when migration completes, the password might have already
expired.
Today we solve this by the async command client_migrate_info, which is expected
to be called before migration starts. The command is completed
once spice client has connected to the destination (or a timeout).
Since async monitor commands are no longer supported, we are looking for a new
solution.
We need to fix async monitor commands. Luiz sent a note our to qemu-devel
recently on this topic.
I'm not sure we'll get there for 1.1 but if we do a 3 month release cycle for
1.2, then that's a pretty reasonable target IMHO.
Regards,
Anthony Liguori
The straightforward solution would be to process the main loop on the
destination side during migration.
(2) In order to restore the source-client spice session in the destination, we
need to pass data from the source to the destination.
Example for such data: in flight copy paste data, in flight usb data
We want to pass the data from the source spice server to the destination, via
Spice client. This introduces a possible race: after migration completes, the
source qemu can be killed before the spice-server completes transferring the
migration data to the client.
Possible solutions:
- Have an async migration state notifiers. The migration state will change after
all the notifiers complete callbacks are called.
- libvirt will wait for qmp event corresponding to spice completing its
migration, and only then will kill the source qemu process.
Any thoughts?
Thanks,
Yonit.
