[Spice-devel] rfc seamless migration

[Gerd Hoffmann]

  Hi,

> I'm still not a big fan of the concept of server data going through the
> client, this means the server
> will need to seriously sanity check what it receives to avoid
> potentially new attacks on it.
> 
> I'm wondering why not do the following:
> 
> 1) spicevmc device gets a savevm call, tell spice-server to send a
> message to the client telling it
> to stop sending more data to *this* server.
> 2) client sends an ack in response to the stop sending data server
> 3) server waits for ack.
> 4) savevm continues only after ack, which means all data which was in
> flight has been received.

Isn't going to fly.  The extra roundtrip time adds to the guests
downtime, we will not get that upstream.

I think we don't need that though.  The guest -> client path isn't
critical, we can just send any pending buffers before sending the
MIGRATE_MSG.

The client -> guest messages can be handled like this:

  * The client keeps a copy of the last few messages.
  * On migration the server informs the client which message was
    the last one committed to the guest.
  * After migration the client can simply resend messages if needed.

We could also extend the spicevmc protocol and have the spice server
explicitly ack each message after it was passed successfully to the
guest.  Then the client can just free the messages once acked instead of
using heuristics for the number of messages to keep.  We also don't have
any special migration state then, after migration the client simply
replays all the (un-acked) messages it has.

This also removes the somewhat silly buffer passing:  data send from the
client to the src spice server (but not yet passed to the guest) is
passed from src spice server back to the client so it can forward it to
the dst spice server ...

>> - list of off-screen surfaces ids that have been sent to the client,
>> and their lossy region.
>> By keeping this data we will avoid on-demand resending surfaces  that
>> already exist on the client side.
> 
> The client already knows which off-screen surfaces ids it has been
> received, so it can just
> send these to the new server without having to receive them from the old
> one first.

Agree.  Any state which the client knows anyway doesn't need to be part
of the MIGRATE_DATA.

cheers,
  Gerd