On 05/14/2013 12:26 AM, nishant burte wrote: > 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? What do you mean, the VM crashed? It's an honest question - there are two levels of crashing: the qemu process that is running the VM crashed [host bug], or the guest itself went into a panic in some way observable by qemu [guest bug]. Right now, qemu can only report the first level of crashing (a qemu failure), and we HOPE those are rare. You can also wire up a watchdog device into your guest, where if the guest doesn't feed the watchdog often enough, then qemu can detect that, again as a first level approximation. There are patches that have been accepted for qemu 1.5, but also depend on using a new enough Linux kernel in the guest, that add a pvpanic device. With that device in place, if the guest detects a panic, then it can write a last-ditch effort message on the dedicated device to give second-level panic reporting. Libvirt still needs to be wired up to expose this second-level reporting in guest XML. Also, while the device could theoretically be used by any guest OS, right now I only know of new enough Linux kernels that know how to use it (that is, I don't know if anyone has written a Windows driver to be installed in a guest to tell qemu when Windows goes into BSOD). > > 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? Other than a watchdog device or a dedicated pvpanic deivce, I don't know of any heartbeat at the qemu level. A guest should run the same as is does on bare metal, so how do you detect when a bare metal machine has gone down? If you can answer that (for example, if you you have a heartbeat at the IP level for deciding when to fence a bare metal guest), then you can also set up that same heartbeat to decide whether a guest is still up - but it would be at a higher level than what qemu/libvirt provide you. At the libvirt layer, we generally try to avoid relying on the guest any more than we have to (it's more secure if you assume the guest is malicious and therefore avoid making your behavior depend on actions by the guest). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list