Re: [Qemu-devel] [PATCH 0/3] client_migrate_switch and auto_switch (RHBZ 725009)

[Alon Levy]

On Fri, Aug 26, 2011 at 11:03:38AM +0100, Daniel P. Berrange wrote:
> On Fri, Aug 26, 2011 at 11:54:49AM +0200, Gerd Hoffmann wrote:
> > On 08/19/11 19:08, Alon Levy wrote:
> > >Fix the ticket expiration on target vm for a spice connection without 
> > >introducing
> > >a race between the spice server switching the client to the new host 
> > >itself and
> > >the target libvirt setting the new expiration date, by adding an option to
> > >client_migrate_info to not automatically switch the client on migration 
> > >completion,
> > >instead waiting for an explicit client_migrate_switch (new monitor 
> > >command) from
> > >libvirt.
> > 
> > Hmm.  Guess the fundamental issue is that libvirt wants to use the
> > monitor to set the ticket instead of the command line for security
> > reasons.  The qemu monitor doesn't accept commands while the
> > incoming migration is running.  We also can't kick the incoming
> > migration via monitor, so first setting the ticket then start
> > migration doesn't work too.  Correct?
> 
> There is actually a reliable window where we can use the monitor
> before incoming migration starts. Libvirt's migration is a 5 stage
> handshake:
> 

So the current suggestion would be to have:

>   1. Begin(src)
>       - Gets current source VM XML config
>   2. Prepare(dst)
>       - Launches QEMU -incoming
>       - Sets passwords, etc to monitor
>   3. Perform(src)
>       - Issue migrate_client_info

client_migrate_info implementation is changes to do:

spice-server sends switch command to spice client, and waits for
a success or error indication from it. Then the monitor command completes
and libvirt continues to the next one. Since this is before migrate
is issued the destination handles the spice client connection.

>       - Issue migrate_set_speed
>       - Issue migrate
>       - Loop
>           - Issue query-migrate
>           - Break if finished/failed
>   4. Finish(dst)
>       - If success
>           - start CPUs
>         Else
>           - Kill QEMU
>   5. Confirm(src)
>       - If success
>           - Kill QEMU
>         Else
>           - Restart CPUs
> 
> Those stages are all serialized, so we can do anything we like
> with the QEMU monitor at stage 2, before stage 3 will start
> back on the src.
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|