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

[Alon Levy <alevy@redhat.com>]

On Mon, Mar 12, 2012 at 10:46:44AM +0100, 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?
> 
> > 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.

Actually, we discussed this in the past and one benefit is that network
between source and target qemu would be fast (otherwise migration
wouldn't work in the first place), as opposed to source->client and
client->dest. Additionally you save one transaction.

> 
> > 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.

Migrate this struct n times for me.

> 
> > 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.
> 
> cheers,
>   Gerd
> 
>