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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list