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

[Hans de Goede]

Hi,

On 03/12/2012 10:46 AM, Gerd Hoffmann wrote:
>    Hi,
>
>> The problem with (b) is, that iirc the way b was implemented in the past
>> was still the big blob approach, but then pass the blob through the client,
>> which means an evil client could modify it, causing all sorts of
>> "interesting"
>> behavior inside spice-server. Since we're re-implementing this to me the
>> send a blob through the client approach is simply not acceptable from a
>> security pov, also see my previous mail in this thread.
>
> Agree.  It should be a normal spice message which goes through the spice
> marshaller for parsing&  sanity checking.
>
>> I disagree. Note that there is more info to send over then just which
>> surfaces / images are cached by the client. There also is things like
>> partial complete agent channel messages, including how much bytes must
>> be read
>> to complete the command, etc.
>
> Is there a complete list of the session state we need to save?
>

There is still code in spice-server for the old seamless migration,
someone could go through that and use that as an initial list of
session state we need to save.

>> IMHO (b) would only be acceptable if the data send through the client stops
>> becoming a blob.
>
> Using (a) to send a blob isn't better.
>

It has the distinct advantage that we can trust the contents of the
blob which makes life significantly easier IMHO.

>> Instead the client could simply send a list of all
>> surface ids,
>> etc. which it has cached after it connects to / starts using the new
>> host. Note
>> that the old hosts needs to send nothing for this, this is info the
>> client already
>> has, also removing the need for synchronization.
>
> Yes, some session state is known to the client anyway so we don't need a
> source<->  target channel for them.
>
>> As for certain other
>> data, such
>> as (but not limited to) partially parsed agent messages, these should be
>> send through the regular vmstate methods IMHO.
>
> That isn't easy to handle via vmstate, at least as soon as this goes
> beyond a fixed number of fields aka 'migrate over this struct for me'.
> Think multiple spice clients connected at the same time.
>
>> 1) Do (a), sending everything that way
>> 2) Do (a) sending non client state that way; and
>>     let the client send state like which surfaces it has cached
>>     when the new session starts.
>
> I think we have to look at each piece of state information needed by the
> target and look how to handle this best.

Agreed, so for starts someone needs to make a list of all
session state we need to save.

Regards,

Hans