[libvirt] Event on domain state change
Hi, In the TODO list I find this line: - event on big domain state change (create, crashed, paused, shutdown, destroy) Because this is a feature that is very useful, I first wonder how libvirt reliably get 'events' itself for example from Xen? From what I can read from xen_internal there is a xenHypervisorGetDomInfo function, but this function should be scheduled in order to see event changes. Even if so, can we be 'quick' enough to detect a destroy? Or determine the difference between a shutdown and a destroy? Stefan
On Sat, May 10, 2008 at 06:12:23PM +0200, Stefan de Konink wrote:
Hi,
In the TODO list I find this line:
- event on big domain state change (create, crashed, paused, shutdown, destroy)
Because this is a feature that is very useful, I first wonder how libvirt reliably get 'events' itself for example from Xen? From what I can read from xen_internal there is a xenHypervisorGetDomInfo function, but this function should be scheduled in order to see event changes. Even if so, can we be 'quick' enough to detect a destroy? Or determine the difference between a shutdown and a destroy?
I don't believe it is possible to distinguish shutdown vs destroy reliably. For QEMU we can trivially get 'events' for create/paused/destroy etc since we're in direct control of QEMU. Xen is a little more tricky - we'd have to register watches against xenstore to get events back. In the absence of this support in libvirt you can infer events by periodically sampling virDomainGetInfo and tracking changes in the state - though of course you can miss some intermediate states. This is what virt-manager does for event tracking. Dan. -- |: Red Hat, Engineering, Boston -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 :|
On Sat, 10 May 2008, Daniel P. Berrange wrote:
I don't believe it is possible to distinguish shutdown vs destroy reliably.
If it was initiated by libvirt itself, I guess we can fire it after we suddenly miss the domain. Destroy would be a direct miss that isn't marked as crashed. (directly leads to the question: does libvirt clean up crashed states?)
In the absence of this support in libvirt you can infer events by periodically sampling virDomainGetInfo and tracking changes in the state - though of course you can miss some intermediate states. This is what virt-manager does for event tracking.
I was thinking about implementing this TODO... With a brainstorm session within our group I also pointed out it would be pretty hard to find a 'within domain' initialised reboot/shutdown. Do you have any clues on that one? Stefan
On Sat, May 10, 2008 at 06:53:29PM +0200, Stefan de Konink wrote:
On Sat, 10 May 2008, Daniel P. Berrange wrote:
I don't believe it is possible to distinguish shutdown vs destroy reliably.
If it was initiated by libvirt itself, I guess we can fire it after we suddenly miss the domain. Destroy would be a direct miss that isn't marked as crashed. (directly leads to the question: does libvirt clean up crashed states?)
In the absence of this support in libvirt you can infer events by periodically sampling virDomainGetInfo and tracking changes in the state - though of course you can miss some intermediate states. This is what virt-manager does for event tracking.
I was thinking about implementing this TODO...
The problem with that TODO (apart the fact it's probably here for 2 years) is that it means adding some kind of asynchronous interfaces, then you get into the problem of hooking in the process main loop, and doing that from a library in a clean way is not trivial. Also we wanted to see if we really needed this, and up to now reasonable polling is good enough for the apps and tools we needed to build (this is also linked to the fact we tried to keep the virDomainGetInfo a very fast operation at least locally). I would be quite happy to never cross that TODO item and found out it's never really needed (asynch programming is bad for your health !) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Stefan de Konink