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
