On 02/08/2010 08:12 AM, Daniel P. Berrange wrote:
For further backgrou, the key end goal here is that in a QMP client, upon receipt of the 'RESET' event, we need to reliably& immediately determine why it occurred. eg, triggered by watchdog, or by guest OS request. There are actually 3 possible sequences - WATCHDOG + action=reset, followed by RESET. Assuming no intervening event can occurr, the client can merely record 'WATCHDOG' and interpret it when it gets the immediately following 'RESET' event - RESET, followed by WATCHDOG + action=reset. The client doesn't know the reason for the RESET and can't wait arbitrarily for WATCHDOG since there might never be one arriving. - RESET + source=watchdog. Client directly sees the reason The second scenario is the one I'd like us to avoid at all costs, since it will require the client to introduce arbitrary delays in processing events to determine cause. The first is slightly inconvenient, but doable if we can assume no intervening events will occur, between WATCHDOG and the RESET events. The last is obviously simplest for the clients.
I really prefer the third option but I'm a little concerned that we're throwing events around somewhat haphazardly.
So let me ask, why does a client need to determine when a guest reset and why it reset?
Regards, Anthony Liguori