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

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, May 25, 2010 at 10:09:55AM -0500, Anthony Liguori wrote:
> On 05/25/2010 09:21 AM, Juan Quintela wrote:
> >They are emitted when migration starts, ends, has a failure or is canceled.
> >
> >+Data: None
> >+
> >+Example:
> >+
> >+{ "event": "MIGRATION_CANCELED",
> >+    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
> >+
> >+MIGRATION_ENDED
> >+---------------
> >+
> >+Emitted when migration ends (both in source and target)
> >   
> 
> A start event is going to be generated already, no?
> 
> >+Data: None
> >+
> >+Example:
> >+
> >+{ "event": "MIGRATION_ENDED",
> >+    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
> >+
> >+MIGRATION_FAILED
> >+----------------
> >+
> >+Emitted when migration fails (both is source and target).
> >+
> >+Data: None
> >   
> 
> There should be some information about why it failed, no? Preferrably in 
> a QError format.
> 
> >+Example:
> >+
> >+{ "event": "MIGRATION_FAILED",
> >+    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
> >+
> >+MIGRATION_STARTED
> >+-----------------
> >+
> >+Emitted when migration starts (both in source and target).
> >   
> 
> I think this makes more sense as a MIGRATION_CONNECTED event.  It 
> probably should carry peer information too.

FYI the original request for these events from a libvirt POV
for in terms of identifying the lifecycle transitions.

Currently we issue a migration commend on source, and then have
to poll very frequently on 'info migrate' to get progress stats,
and to determine completion. We want to poll much less frequently
for stats, and get async notification of completion/errors on the
source. 

Simiarly on the destination, we need to know when any migration
operation is taking place, so we can avoid issuing monitor
commands to the QEMU process during that time, and also track
success/failure + eventually get progress information via an
equivalent of 'info migrate' on destination.

So this is really focused on lifecycle transitions, rather than
network client connections. I'm not convinced that we should mix
up the two sorts of data. If we want to track network client
connections IMHO they ought to be separate events. Perhaps
there should be a generic QEMU  network CONNECT/DISCONNECT
event that works for all QEMU network sockets (migration, chardevs,
netdev sockets, vnc, spice, and whatever we invent in future using
sockets).


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|