[libvirt] latency between LIFECYCLE event and notification generation

[Eric Blake]

On 05/11/2013 07:41 AM, nishant burte wrote:
> Hi,
> 
> 
> I want to know following about LIFECYCLE events of libvirt.
> 
> 1. about the the latency of these events happening and notification
> generation.
> e.g. suppose a VM goes down. How much time it takes to realize that the
> particular VM has gone down(going to say, DEFINED state) and then
> notification is generated?

Libvirt is not a real-time scheduler.  We make no guarantees about when
events will be delivered, and while it is likely that events are
delivered in order, I'm not even brave enough to state that libvirt even
guarantees in-order delivery to remote hosts.  All I know is that
libvirt tries to deliver events as soon as it knows about them, but that
events are always best-effort, and you have to be prepared for guest
state to have changed yet again in between when libvirt detected that an
event should be delivered and when your code receives the event.

> 
> 2. Second question is, can someone please explain what are the sequence of
> steps happen between a VM going down and the notification is generated?

How is the guest shutting down?  Guest-initiated action, libvirt
shutdown request, or libvirt destroy request?  Are you interested in the
specifics used by the qemu hypervisor, or in the lifecycle events in
general without regards to which hypervisor?  You may be best off trying
to use the sample programs shipped as part of libvirt (see
examples/domain-events/events-{c,python} in libvirt.git) to see what
events are triggered in response to which actions.  [And someday, I'd
like to teach virsh to deal with events]

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130513/5f0be6a7/attachment-0001.sig>