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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list