[Spice-devel] rfc seamless migration

[Alon Levy]

On Sun, Jun 10, 2012 at 05:11:06PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 06/10/2012 04:44 PM, Alon Levy wrote:
> 
> <snip>
> 
> >>>Obligatory migration data:
> >>>-------------------------
> >>>(1) agent/spicevmc/smartcard write buffer. i.e., data that reached the server after savevm, and thus was not written to the device.
> >>>Currently, spicevmc and smartcard do not have write buffer, but since buffers can reach the server after savevm, they should have one. I'm not sure if even today they should attempt to write to the guest if it is stopped. The agent code also can write to the guest even if it is stopped; I think it is a bug.
> >>>(2) agent/smartcard partial data that had been read from the device and wasn't sent to the client since its reading hasn't completed.
> >>>Currently we don't have such data for spicevmc, because we push to the client any amount of data we read. In the future we might want to control the rate and the size of data we send/receive, and then we will have outgoing buffer.
> >>
> >>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.
> >
> >Have you seen the qemu-devel thread Yonit referred to in the beginning?
> >Let me quote:
> >"
> >Spice is *not* getting a hook in migration where it gets to add
> >arbitrary amounts of downtime to the migration traffic.  That's a
> >terrible idea.
> >"
> 
> Hmm, bummer, I still believe a solution like the one I outlined would have been both better
> and *simpler*. But alas, looks like we really need to do this the hard way then...
> 
> That still leaves this worry though:
> 
> >>>(c) As for security issues, I don't think that it should raise a problem since the client is trusted by both the src and the target.
> >>
> >>The client is trusted to access the *vm*, not the *host*, and this allows attacks on spice-server,
> >>which is running on the *host*.

The client talks to the host, i.e. to the qemu instance running the vm.
It doesn't talk to the vm directly. It's already open for attacks from
the client.

Don't mean to say we shouldn't verify the data, but I don't think it's a
new requirement.

> 
> 
> Which means we need to be very very careful, and preferably use this mechanism as little as possible.
> 
> Regards,
> 
> Hans
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel