[Spice-devel] [RFC PATCH spice 0.8 01/19] server/spice.h: semi-seamless migration interface, RHBZ #738266

[Yonit Halperin]

On 09/19/2011 07:13 PM, Gerd Hoffmann wrote:
>   Hi,
>
>> We need to handle another case: New client. New source server. Old
>> target server.
>
> Indeed.
>
>> 2. When client connects to the server it sees that the server doesn't
>> have the SEMI_SEAMLESS_CAP present. So it disconnects, and sends to
>> the source a
>> SPICEC_MSG_MIGRATE_TARGET_CONNECTION_FAILED_TARGET_TOO_OLD , or maybe
>> just a generic error message (if we have something like that) and use
>> that as the reason. The server sees this, and proceeds to do the old
>> switch host behavior.
>
> Sounds good to me.
>
>>>> This looks a bit like seamless migration half-done. What is
>>>> missing to full seamless migration support? The spice channels
>>>> need to transfer the state via client. Also qemu on the source
>>>> needs to wait for that to complete I guess? Anything else?
>
>>> We are still missing keeping the target stopped till the target
>>> spice server is restored from the data passed through the client.
>>> Thanks to the fix Alon sent for RHBZ #729621, we could block the
>>> target from starting using a vm state change handler, but it is a
>>> workaround... IMHO, if we could have async notifiers for migration
>>> before it starts and just before it completes (as we had in Rhel5),
>>> that would have been the best solution (it will also allow us not
>>> to use client_migrate_info for the pre-connection to the target).
>
> For now I'll try to see the big picture (aka API needed), not the little
> implementation details. Whenever we kick off the migration from the
> client_info or the migration notifier doesn't matter for the
> libspice-server API, that is an detail which can easily be changed once
> we have the notifiers in place.
>
> The steps needed for seamless migration, qemu on the source:
>
> (1) spice_server_migrate_info()
>
> (2) spice_server_migrate_start()
>
> (3) wait for the callback, async needed as the vm is running.
>
> (4) do migration, live stage.
>
> (5) stop virtual machine (and qxl worker).
>
> (6) Guess we need to notify spice-server here?
> Maybe call spice_server_migrate_start() here and rename the
> call in (2) to spice_server_migrate_connect() ?
>
> (7) do migration, non-live stage.
>
> (8) spice_server_migrate_end().
>

(A) Is it possible to hold the target paused (but not blocked) after the 
non-live stage completes? If it is possible (6) is not necessary as long 
as spice_server_migrate_end will be called before the target vm is started.


> Qemu on the target:
>
> (1) receive migration
>
> (2) wait for spice-server to complete client migration
> [ need api for that ]
>
(B) If the answer for (A) is yes, maybe this should be done through the 
client and the src server:
(1) target spice-server completes client migration, acks the client,
(2) the client disconnects from the src or sends an appropriate message 
to the src server
(3) src server completes spice_server_migrate_end (async?), and make the 
target vm start.

If the answer for (A) is no, then spice will need qemu to have a 
migration completion async notifier in the target side as well.

> (3) start virtual machine (and qxl worker).
>
> Correct?
>
> semi-seamless should work with that workflow too, even though
> spice-server probably hasn't anything to do at source step (6) and
> target step (2), correct?
Yes
>
> cheers,
> Gerd
>