Re: [Qemu-devel] [Spice-devel] seamless migration with spice

[Yonit Halperin <yhalperi@redhat.com>]

Hi,
On 03/13/2012 08:40 AM, Gerd Hoffmann wrote:
> On 03/12/12 19:45, Yonit Halperin wrote:
>> Hi,
>> On 03/12/2012 03:50 PM, Gerd Hoffmann wrote:
>>>     Hi,
>>>
>>>> Can you explain/exemplify, why sending data as a blob (either by (a) or
>>>> (b)), that is verified only by the two ends that actually use it, is a
>>>> problem?
>>>
>>> It tends to be not very robust.  Especially when the creating/parsing is
>>> done ad-hoc and the format changes now and then due to more info needing
>>> to be stored later on.  The qemu migration format which has almost no
>>> structure breaks now and then because of that.  Thus I'd prefer to not
>>> go down this route when creating something new.
>>>
>>> cheers,
>>>     Gerd
>>
>> Exposing spice server internals to the client/qemu seems to me more
>> vulnerable then sending it as a blob.
>
> That also depends on what and how much we need to transfer.
>
>> Nonetheless, it introduces more
>> complexity to backward compatibility support and it will need to involve
>> not only the capabilities/versions of the server but also those of the
>> qemu/client
>
> Backward compatibility isn't that easy both ways.
>
It is not easy when you have 2 components, and it is much less easy when 
you have 3 or 4 components. So why make it more complicated if you can 
avoid it. Especially since there is no functional reason for making the 
qemu/client capabilities/versions dependent on the server internal data.
>> .Which reminds me, that we also need capabilities
>> negotiation for the migration protocol between the src and the destination.
>
> If this is a hard requirement then using the vmstate channel isn't going
> to work.  The vmstate is a one-way channel, no way to negotiate anything
> between source and target.
>
We can do this via the client.

Regards,
Yonit.
> cheers,
>    Gerd