[Spice-devel] migration and qemu/spice versions

[Yonit Halperin]

On 09/06/2011 02:03 PM, Gerd Hoffmann wrote:
> 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.
>
o.k. I will call both.
>> 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.
>
I was talking about adding a new interface (which inherits from 
SpiceBaseInterface) dedicated to migration. I think it will be more 
elegant to use it both for future callbacks and for the current 
necessity for backward compatibility support.

Thanks,
Yonit.

> cheers,
> Gerd