[Spice-devel] rfc seamless migration

[Hans de Goede]

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


Which means we need to be very very careful, and preferably use this mechanism as little as possible.

Regards,

Hans