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

[Hans de Goede]

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.

> 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