Re: [Qemu-devel] seamless migration with spice

[Yonit Halperin]

Hi.
On 03/11/2012 05:36 PM, Anthony Liguori wrote:
> On 03/11/2012 10:25 AM, Alon Levy wrote:
> > On Sun, Mar 11, 2012 at 09:18:17AM -0500, Anthony Liguori wrote:
> > > On 03/11/2012 08:16 AM, Yonit Halperin wrote:
> > > > Hi,
> > > >
> > > > We would like to implement seamless migration for Spice, i.e.,
> > > > keeping the
> > > > currently opened spice client session valid after migration.
> > > > Today, the spice client establishes the connection to the
> > > > destination before
> > > > migration starts, and when migration completes, the client's session
> > > > is moved to
> > > > the destination, but all the session data is being reset.
> > > >
> > > > We face 2 main challenges when coming to implement seamless migration:
> > > >
> > > > (1) Spice client must establish the connection to the destination
> > > > before the
> > > > spice password expires. However, during migration, qemu main loop is
> > > > not
> > > > processed, and when migration completes, the password might have
> > > > already expired.
> > > >
> > > > Today we solve this by the async command client_migrate_info, which
> > > > is expected
> > > > to be called before migration starts. The command is completed
> > > > once spice client has connected to the destination (or a timeout).
> > > >
> > > > Since async monitor commands are no longer supported, we are looking
> > > > for a new
> > > > solution.
> > >
> > > We need to fix async monitor commands. Luiz sent a note our to
> > > qemu-devel recently on this topic.
> > >
> > > I'm not sure we'll get there for 1.1 but if we do a 3 month release
> > > cycle for 1.2, then that's a pretty reasonable target IMHO.
> >
> > What about the second part? it's independant of the async issue.
>
> Isn't this a client problem? The client has this state, no?
No, part of the data is server specific.

> If the state is stored in the server, wouldn't it be marshaled as part
> of the server's migration state?
We currently don't restore the server state. That is the problem we want 
to solve.
I meant that the server state can be marshaled from the source to the 
client, and from the client to the destination. The client serves as the 
mediator.
Another option that we thought about was using save/load vmstate.

Regards,
Yonit.
> I read that as the client needs to marshal it's own local state in the
> session and restore it in the new session.


> Regards,
>
> Anthony Liguori
>
> > > Regards,
> > >
> > > Anthony Liguori
> > >
> > > > The straightforward solution would be to process the main loop on the
> > > > destination side during migration.
> > > >
> > > > (2) In order to restore the source-client spice session in the
> > > > destination, we
> > > > need to pass data from the source to the destination.
> > > > Example for such data: in flight copy paste data, in flight usb data
> > > > We want to pass the data from the source spice server to the
> > > > destination, via
> > > > Spice client. This introduces a possible race: after migration
> > > > completes, the
> > > > source qemu can be killed before the spice-server completes
> > > > transferring the
> > > > migration data to the client.
> > > >
> > > > Possible solutions:
> > > > - Have an async migration state notifiers. The migration state will
> > > > change after
> > > > all the notifiers complete callbacks are called.
> > > > - libvirt will wait for qmp event corresponding to spice completing its
> > > > migration, and only then will kill the source qemu process.
> > > >
> > > > Any thoughts?
> > > >
> > > > Thanks,
> > > > Yonit.