[Spice-devel] rfc seamless migration

[Alon Levy]

On Mon, Jun 11, 2012 at 09:25:46AM +0200, Gerd Hoffmann wrote:
>   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.

This is a lot of work for infrequent migration. I don't think the silly
buffer passing is that silly compared to this. Also, this is not always
enough, like you say below - heuristic for the amount of messages to
keep. On the other hand the buffer passing scheme is always correct.

>   * 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