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

[Yonit Halperin]

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