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