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

[Alon Levy]

On Thu, Mar 15, 2012 at 03:34:19PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 03/15/2012 03:22 PM, Alon Levy wrote:
> >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.
> 
> There seems to be more state in spice/server/smartcard.c then just
> buffers, ie if a reader is attached or not. Then again that seems
> to reflect whether a client is connected to the channel or not,
> so you're probably right.
> 
> Hmm, interesting you allow for multiple smartcard chardevs in theory,
> but then in smartcard_char_device_add_to_readers you unconditionally
> call smartcard_init which does:
> 
> SmartCardChannel *g_smartcard_channel;
> 
> static void smartcard_init(void)
> {
>     ChannelCbs channel_cbs = { NULL, };
>     ClientCbs client_cbs = { NULL, };
> 
>     ASSERT(!g_smartcard_channel);
> 
> <snip>
> 
>     g_smartcard_channel = (SmartCardChannel*)red_channel_create(sizeof(...
> 
> So in essence you allow only 1 smartcard chardev, and registering a
> second will trigger the ASSERT (if enabled), or override
> g_smartcard_channel ...
> 
> Not really migration related just something I noticed.

Thanks, I'll try to fix that.

> 
> Regards,
> 
> Hans
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel