[Spice-devel] [Qemu-devel] seamless migration with spice
Yonit Halperin
yhalperi at redhat.com
Mon Mar 12 23:52:53 PDT 2012
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
More information about the Spice-devel
mailing list