[Spice-devel] changing the timing of spice client linking in migration (RHBZ #725009)

[Gerd Hoffmann]

   Hi,

>> race 2: target starts before it manages to restore the source
>> pre-migration state (which was sent to it from the src server, via the
>> client).
>> solution:
>> the target won't attach any spice device interface till it restores its
>> state (with timeout). i.e., it will queue any request from the quest,
>> and will operate on them only after it has been restored.

>  From the vm_start code (vl.c), it looks like the start notifier is
> called before the guest is actually started, so we can hold the target
> from starting till we recover it. Gerd, is this correct?

Yes, the notifier is called first.

>> other changes in spice:
>> due to the broken seamless migration, spice channels were not maintained
>> to keep supporting it (i.e., sending the minimal amount of data that is
>> required for the target to restore the channel's state), especially the
>> new channels (smartcard, usb(?), agent transmissions, etc.). So,
>> implementation in this level is required as well.
>>
> Arnon, Alon, Hans, can you let me know how much work it would be to
> support seemless migration for agent, smartcard, and usb (is it relevant
> for rhel 6.3?)? Supporting seemless migration mainly requires (1)
> sending SPICE_MSG_MIGRATE_DATA with data that will allow the target side
> to be restored, so that the connection with the same client will stay
> valid. (2) handle SPICE_MSGC_MIGRATE_DATA in the target

Do we have to support seamless migration for all channel types?  Or is 
it an option to support it for some channel types only to avoid 
complexity if we don't need it?

I see the point in doing it for the display channel, all the surfaces in 
the client cache will stay valid which will avoid alot of data being 
resent to the client.

For the input channel it is alot less important.  The agent should also 
be able to just re-build the connection and be happy.  Likewise the 
smartcard.  Not sure about sound, might be important because of mm_time 
and a/v sync.

For USB it would certainly be nice to have, especially for stuff like 
usb sticks where you want avoid the guest see a disconnect+reconnect for 
a device which might have outstanding write requests.  It is tricky 
though as the data travels both ways (which is quite different from 
display channel), so a simple SPICE_MSG_MIGRATE_DATA message might not 
be enougth to handle seamless migration for usb.

cheers,
   Gerd