[Spice-devel] [Qemu-devel] seamless migration with spice

[Alon Levy]

On Thu, Mar 15, 2012 at 01:36:23PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 03/15/2012 01:11 PM, Yonit Halperin wrote:
> >On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
> >>Hi,
> >>
> >>>It is not easy when you have 2 components, and it is much less easy when
> >>>you have 3 or 4 components. So why make it more complicated if you can
> >>>avoid it. Especially since there is no functional reason for making the
> >>>qemu/client capabilities/versions dependent on the server internal data.
> >>
> >>qemu has ways to handle compatibility in the vmstate format. We can use
> >>those capabilities. That of course requires exposing the structs to be
> >>saved to qemu and adds some complexity to the qemu<-> spice interface.
> >>
> >>What session state is needed by the target?
> >>What of this can be negotiated between client and target host without
> >>bothering the source?
> >>What needs be transfered from source to target, either directly or via
> >>client?
> >>
> >>>>If this is a hard requirement then using the vmstate channel isn't going
> >>>>to work. The vmstate is a one-way channel, no way to negotiate anything
> >>>>between source and target.
> >>>>
> >>>We can do this via the client.
> >>
> >>Then you can send the actual state via client too.
> >>Out-of-band negotiation for the blob send via vmstate scares me.
> >>
> >>Can we please start with a look at which state we actually have to send
> >>over?
> >Ok, I can take the display and sound channels.
> >Alon, can you take the smartcard?
Smartcard is actually using spicevmc state in qemu as well - the qemu
part is the same as the usb part, uses spicevmc chardev. And there is
already vmstate for the ccid-card-passthru device. In flight messages
can be dealt with the same way Hans suggested for spicevmc channel as
well.

The channel itself has a buffer it needs to save unless we go the same
route Hans suggested and flush it. IIRC there are messages for doing
that in the protocol already - server asks client to get ready for
migration, client notifies server when it is ready. Server can pass all
messages it has to write to client before sending it PREPARE_TO_MIGRATE,
then it can push anything it gets from the client to qemu (hmm, that
could take an undefined amount of time if spicevmc/usb ccid are not
processing it fast enough), while not polling qemu for new stuff, and
the client shouldn't be sending anything new anyway after the
PREPARE_TO_MIGRATE.

> >Hans, spicevmc?
> 
> Easy, the spicevmc channel has no state which needs to be migrated, except
> for things in the red_channel_client base class:
> 
> 1) Partially received spice messages
> 2) Possible pending pipe items when writes from qemu -> client have blocked.
> 
> I assume that the red_channel_client base class will handle migrating them,
> if we migrate them at all.
> 
> Instead of migrating we could:
> For 1. expect the client to stop sending new messages at a certain point
> during the migration, and ensure we've processed any pending messages
> after this point.
> 

> For 2. we could flush pending items and set a flag to stop channel
> implementations from queuing new ones, at which point for spicevmc the
> data will get queued inside qemu and migrating it no longer is
> a spice-server problem to migrate it (and we need migration support for
> the data possibly queued inside qemu anyways).
> 
> Regards,
> 
> Hans