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

[Alon Levy]

On Fri, Aug 26, 2011 at 12:17:58PM +0200, Gerd Hoffmann wrote:
> On 08/26/11 12:03, 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:
> >
> >   1. Begin(src)
> >       - Gets current source VM XML config
> >   2. Prepare(dst)
> >       - Launches QEMU -incoming
> >       - Sets passwords, etc to monitor
> >   3. Perform(src)
> 
> >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.
> 
> Ok, so I think we should be able to fix the race outlined above
> without adding new monitor commands, just by letting libvirt set the
> spice ticket in stage 2.

Is that different then what I suggested in my reply to Daniel's 5 stage outline?

> 
> cheers,
>   Gerd
> 
>