[libvirt] PATCH: Add domain event "detail" information

[Daniel Veillard]

On Mon, Nov 17, 2008 at 01:27:26PM +0000, Daniel P. Berrange wrote:
> On Mon, Nov 17, 2008 at 01:05:30PM +0000, Daniel P. Berrange wrote:
> > On Mon, Nov 17, 2008 at 01:03:29PM +0100, Daniel Veillard wrote:
> > > On Fri, Nov 14, 2008 at 05:44:29PM +0000, Daniel P. Berrange wrote:
> > > > As per our earlier discussion today, this patch expands the callback for
> > > > domain events so that it also gets a event type specific 'detail' field.
> > > > This is also kept as an int, and we define enumerations for the possible
> > > > values associated with each type.
> > > [...]
> > > 
> > >   Okay, that made the overall callbacks set clearer, ACK
> > > 
> > > > If a event type has no detail, 0 is passed.
> > > 
> > >   Actually I would define a detail enum for all event type just to
> > > make clear what the value will be and expose how it's intended to be
> > > extended if needed.
> 
> This new patch does that now.

  Okay, just one minor suggestion, in eventDetailToString() make a case
for all event types and drop default: so the compiler warns us if we
forgot to update the function when there is an addition to one of the
enums.

> > > 
> > > > A word about migration...
> > > > 
> > > >  - The destination host first gets a STARTED event, with detail MIGRATED
> > > >    when it starts running
> > > >  - The source host then gets a STOPPED event with detail MIGRATED when
> > > >    it completes
> > > 
> > >   What about 'live' migration, i.e. events sent when the migration flows
> > > begin but the domain is stil running. I don't know if KVM has this but
> > > on Xen I would expect to be able to notice this. On the target host that
> > > could be indicated by SUSPENDED + VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED
> > > because it will consume the memory resource like a suspended domain but
> > > no actual CPU cycle (well except for migration itself). On the source
> > > host this is a bit harder to indicate, maybe this isn't needed as the
> > > resource usage doesn't really change at that point.
> > 
> > The problem with live migration is that, by definition, there is no change
> > in the domain on the source host until migration is complete. It remains
> > in the 'running' state the entire time and does not undergo any lifecycle
> > transitions, so there's no event we could generate for the start of a
> > migrate event on the source. Only the destination host gets an explicit
> > lifecycle change at the start & end of migration operation.
> > 
> > For non-live migration of course, you would get a transition from the
> > running state, to the paused state on the source host when migration
> > starts, and that actually does mean we need to define another enum for
> > 'detail' on the 'suspended' and 'resumed' events too.
> 
> Turns out the QEMU  migration implementation was incorrectly ignoring the
> 'flags' argument and doing all migration operations as 'live'. So this
> patch fixes that, to pause the VM before migration if non-live was requested.
> It'll emit  VIR_DOMAIN_EVENT_SUSPENDED, with detail field value of
> VIR_DOMAIN_EVENT_SUSPENED_MIGRATED when starting a non-live migration.
> I also fixed the patch to use VIR_DOMAIN_EVENT_RESUMED_MIGRATED when the
> migration operation completes on the destination.

  Okay, +1

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/