Re: [Qemu-devel] seamless migration with spice

[Gerd Hoffmann <kraxel@redhat.com>]

  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.

I think (b) is the better approach.

cheers,
  Gerd