[Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events

[Anthony Liguori]

On 05/26/2010 05:33 AM, Daniel P. Berrange wrote:
> > > I'm not sure why you would need a notification of when migration
> > > starts (since you know when you've started migration).
> > >        
> > But you don't know if the other end "knows" that it has also started.
> >
> > started is needed only in incoming part, because .... we don't have a
> > monitor to ask if migration has started.
> >      
> If we ever want to get closer to allowing multiple monitors, or allowing
> apps to issue QMP commands directly via libvirt, then we still need the
> 'migration started' event on the source, because something else can
> have issued the 'migrate' command without the mgmt app knowing.
>    

Migration started doesn't help multiple monitors.  You need locking of 
some sort.

Part of the problem is the QMP migrate command is implemented as a 
synchronous command.  It really ought to be an asynchronous command.  
That tells you when the migration has actually completed without polling.

On the source end, I can't think of any events that would be useful.  
The migrate command can complete with a failure so that gives you 
failure notifications.

On the destination side, we're really limited by the fact that we don't 
do live incoming migrations.  The monitor doesn't get a chance to run at 
all with exec: migration, for instance.

For tcp: and unix:, a CONNECTED event absolutely makes sense (every 
socket server should emit a CONNECTED event).  Unfortunately, after 
CONNECTED you lose the monitor until migration is complete.  If 
something bad happens, you have to exit qemu so once the monitor 
returns, migration has completed successfully.

If we introduce live incoming migration, we'll need to rethink things.  
I would actually suggest that we deprecate the incoming command if we do 
that and make incoming migration a monitor command.  I would think it 
should have the same semantics as migrate (as an asynchronous command).  
A CONNECTED event still makes sense for tcp and unix protocols but I 
don't think events make sense for start stop vs. an asynchronous command 
completion.

Regards,

Anthony Liguori

> MIGRATED_STARTED+STOPPED really *is* needed if we're to make QMP cope
> with all possible use cases. If we rely on inferring it from STOP+RESUME
> events, it is going to exclude a significant set of use cases, and likely
> result in this being proposed all over again in 12 months time :-(
>
> Regards,
> Daniel
>