[libvirt] latency between LIFECYCLE event and notification generation

[nishant burte]

Thanks Eric and Daniel for the response.
For the 2nd question, let me elaborate more.

>
> 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?

Lets say, the VM crashed. The question is, how does qemu (or hyperviser )
come to know about it? and how does it generate notification?

e.g. I am looking for explanation something on following lines.
VM pings hyperviser periodically, when it is UP. When these heartbeats
stop, hyperviser detects VM has gone down and then it sends the
notification to libvirt.

Could you please give sequence of events on similar lines as given above?

Thanks
Nishant


On Mon, May 13, 2013 at 9:31 PM, Daniel P. Berrange <berrange at redhat.com>wrote:

> On Mon, May 13, 2013 at 09:44:35AM -0600, Eric Blake wrote:
> > 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.
>
> FYI, we *do* guarantee to deliver events to clients in exactly the
> same order that libvirtd detects the events, even to remote hosts,
> and we do not drop events. The RPC protocol is strictly serialized
> in its dispatch of events.
>
> We make no guarantees about latency though. There can be an arbitrary
> delay between libvirtd detecting the event & the client receiving it,
> though of course we aim to keep this latency as small as we can.
>
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org              -o-             http://virt-manager.org:|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/:|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc:|
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130514/264ff155/attachment-0001.htm>