11:12 a.m.
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
11:40 a.m.
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 :|
11:53 a.m.
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
9:18 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6070
days inactive
6075
days old
3 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Stefan de Konink