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.
I don't make use of 'CRASHED' in QEMU driver yet. It might be useful in Xen though - when a PV guest crashes, Xen stops the domain running, but leaves it there in a shutoff state, but marked as crashed.
Now using the C event-test program you can see the effects:
myDomainEventCallback1 EVENT: Domain F9x86_64(2) Started Booted myDomainEventCallback2 EVENT: Domain F9x86_64(2) Started Booted myDomainEventCallback1 EVENT: Domain F9x86_64(-1) Stopped Destroyed myDomainEventCallback2 EVENT: Domain F9x86_64(-1) Stopped Destroyed myDomainEventCallback1 EVENT: Domain F9x86_64(3) Started Booted myDomainEventCallback2 EVENT: Domain F9x86_64(3) Started Booted myDomainEventCallback1 EVENT: Domain F9x86_64(3) Suspended myDomainEventCallback2 EVENT: Domain F9x86_64(3) Suspended myDomainEventCallback1 EVENT: Domain F9x86_64(3) Resumed myDomainEventCallback2 EVENT: Domain F9x86_64(3) Resumed myDomainEventCallback1 EVENT: Domain F9x86_64(-1) Stopped Shutdown myDomainEventCallback2 EVENT: Domain F9x86_64(-1) Stopped Shutdown
Of the following sequence of actions
virsh start F9x86_64 virsh destroy F9x86_64 virsh start F9x86_64 virsh suspend F9x86_64 virsh resume F9x86_64 virsh shutdown F9x86_64
For the last 'shutdown' operation, you'll see the same if you just run a graceful shutdown inside the guest itself.
okay
NB, I've not tested saved/restored because my install of KVM is not new enough to support that correctly, but I expect it to work without trouble. Likewise for migration.
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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|