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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/