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

[David Jaša]

Hans de Goede píše v Po 12. 03. 2012 v 09:51 +0100:
> Hi,
> 
> On 03/12/2012 08:57 AM, Gerd Hoffmann wrote:
> >    Hi,
> >
> >>> What about the second part? it's independant of the async issue.
> >>
> >> Isn't this a client problem?  The client has this state, no?
> >
> > It is state of the client<->  server session.  Today spice client
> > creates a new session on migration, so there is simply no need to
> > maintain any state.  Drawback is that everything needs to be resent from
> > the server to the client.  Thats why we want be able to continue the
> > spice session, so the client caches will stay valid.
> >
> > Of course the spice-server on the migration target needs the session
> > state for that, i.e. know for example which bits the client has cached
> > which it hasn't.
> >
> >> If the state is stored in the server, wouldn't it be marshaled as part
> >> of the server's migration state?
> >
> > spice-server is stateless today when it comes to migration.  QXL handles
> > all (device) state, by keeping track of some commands (such as
> > create/destroy surface) which it needs to transfer on migration, and by
> > asking spice-server to render all surfaces on migration, which
> > effectively flushes the spice server state to qxl device memory.
> >
> > To transfer the client session state there are basically two options:
> >
> >    (a) transfer it as part of the qemu migration data stream.  I don't
> >        want have any details about the qemu migration implementation
> >        and/or protocol in the spice-server library api, which basically
> >        leaves a ugly "transfer-this-blob-for-me-please" style interface
> >        as only option.
> >
> >    (b) transfer it as part of the spice protocol.  As the spice
> >        client has a connection to both source and target while the
> >        migration runs we can send session state from the source host via
> >        spice client to the target host.  This needs some form of
> >        synchronization, to make sure both vmstate and spice migration
> >        are completed when qemu on the source machine quits.
> 
> 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.
> 

In addition to security POV, it's also bad from network usage POV -
while network connection among hosts is gigabit or better, client may be
connected over high-latency low-bandwidth WAN. Sending any data through
client makes absolutely no sense in such cases.

David

> > I think (b) is the better approach.
> 
> 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.
> 
> IMHO (b) would only be acceptable if the data send through the client stops
> becoming a blob. 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. 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.
> 
> So I see 2 options
> 
> 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.
> 
> Regards,
> 
> Hans
> _______________________________________________
> Spice-devel mailing list
> address@hidden
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24