<div dir="ltr"><div><div>Thanks Eric and Daniel for the response.<br></div>For the 2nd question, let me elaborate more.<br><br>><br>
> 2. Second question is, can someone please explain what are the sequence of<br>
> steps happen between a VM going down and the notification is generated?<br>
<br></div>Lets say, the VM crashed. The question is, how does qemu (or hyperviser ) come to know about it? and how does it generate notification?<br><br>e.g. I am looking for explanation something on following lines.<br>

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.<br><div><br></div><div>Could you please give sequence of events on similar lines as given above?<br>

<br></div><div>Thanks<br>Nishant<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 13, 2013 at 9:31 PM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, May 13, 2013 at 09:44:35AM -0600, Eric Blake wrote:<br>
> On 05/11/2013 07:41 AM, nishant burte wrote:<br>
> > Hi,<br>
> ><br>
> ><br>
> > I want to know following about LIFECYCLE events of libvirt.<br>
> ><br>
> > 1. about the the latency of these events happening and notification<br>
> > generation.<br>
> > e.g. suppose a VM goes down. How much time it takes to realize that the<br>
> > particular VM has gone down(going to say, DEFINED state) and then<br>
> > notification is generated?<br>
><br>
> Libvirt is not a real-time scheduler.  We make no guarantees about when<br>
> events will be delivered, and while it is likely that events are<br>
> delivered in order, I'm not even brave enough to state that libvirt even<br>
> guarantees in-order delivery to remote hosts.  All I know is that<br>
> libvirt tries to deliver events as soon as it knows about them, but that<br>
> events are always best-effort, and you have to be prepared for guest<br>
> state to have changed yet again in between when libvirt detected that an<br>
> event should be delivered and when your code receives the event.<br>
<br>
</div>FYI, we *do* guarantee to deliver events to clients in exactly the<br>
same order that libvirtd detects the events, even to remote hosts,<br>
and we do not drop events. The RPC protocol is strictly serialized<br>
in its dispatch of events.<br>
<br>
We make no guarantees about latency though. There can be an arbitrary<br>
delay between libvirtd detecting the event & the client receiving it,<br>
though of course we aim to keep this latency as small as we can.<br>
<span class="HOEnZb"><font color="#888888"><br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a>      -o-    <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a>              -o-             <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a>       -o-         <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a>       -o-       <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</font></span></blockquote></div><br></div>