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

[Gerd Hoffmann]

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

That is on the list below for the target qemu ;)

We will need that no matter what, we might have to create some 
infrastructure for that though.  I think this pretty much implies that 
the target qemu needs to tell the spice server somehow whenever it can 
handle this (and thus support seamless migration), so spice-server can 
set the capabilities on the main channel accordingly.

> If it is possible (6) is not necessary as long
> as spice_server_migrate_end will be called before the target vm is started.

But I think it will help keeping the vm downtime low because the final 
stage of vm migration and spice seamless migration can run in parallel. 
  At least the display channel which runs in its own thread should 
benefit from that.  For the other channels it probably isn't a big 
difference today due to qemu not listening on the sockets.  That might 
change in the future though.

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

Oh, I think I misunderstood your quesion above.  I think we should 
handle this completely on the target side, i.e. have qemu wait for both 
vm migration and spice client migration finish before re-starting the 
guest (leaving aside for now how we are going to actually implement 
that). That should be more robust than doing some kind of syncronization 
using the client.  There is no need to handle icky corner cases like the 
client just exiting the moment you want use it to send a notification to 
the other qemu.

cheers,
   Gerd