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

[Gerd Hoffmann]

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

Qemu on the target:

   (1) receive migration

   (2) wait for spice-server to complete client migration
       [ need api for that ]

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

cheers,
   Gerd