[Spice-devel] migration and qemu/spice versions

[Gerd Hoffmann]

On 09/06/11 12:14, Yonit Halperin wrote:
> On 09/06/2011 01:03 PM, Gerd Hoffmann wrote:
>> On 09/06/11 11:54, Yonit Halperin wrote:
>>> Hi,
>>> I'm working on the changes discussed in the thread "changing the timing
>>> of spice client linking in migration (RHBZ #725009)".
>>> In order to be backward compatible with respect to spice-server and qemu
>>> we need
>>> (1) new qemu calling the old switch_host if the server is old (instead
>>> of spice_server_migrate_end)
>>
>> New qemu can just call spice_server_migrate_start() and check the return
>> value. If it succeeds just go on with seamless migration, otherwise
>> (return value < 0) fallback to switch-host.
>>
>>> (2) new spice-server using the old switch host (and not the new
>>> migration mechanism) if qemu is old.
>>
>> Old qemu which can't handle seamless migration will never ever call
>> spice_server_migrate_start().
>>
>> cheers,
>> Gerd
>>
> This would work, but IMHO it is less readable:
> 1) I don't plan to use spice_server_migrate_start. We will tell the
> client to connect to the target upon client_migrate_info.

Those implementation details should not be coded into the spice server 
library interface and preferable also not into the (monitor) interface 
between qemu and libvirt.

Maybe qemu can accept incomming connections in parallel to the incoming 
migration some day.  We want to use that to parallelize spice client and 
vm migration.  It would be great if all we have to touch for that is 
qemu itself, without any worries how to handle backward compatibility.

The client_migrate_info monitor handler can call both 
spice_server_migrate_info() and spice_server_migrate_start().  If we 
want separate these to actions some day -- no problem, we can just move 
the spice_server_migrate_start() call to another place.

> 2) Maybe the interface for migration will have more changes in the
> future. Actually, maybe also for this feature, if libvirt will support
> an async client_migrate_info, and we will need an interface for calling
> the appropriate callback.

Adding a new callback to the core interface is easy.  Have a look at the 
changeset which adds the channel_event callback to see how to do it.

cheers,
   Gerd