Anthony Liguori <anth...@codemonkey.ws> writes: > On 02/23/2011 11:18 AM, Avi Kivity wrote: >> On 02/23/2011 06:28 PM, Anthony Liguori wrote: >>> >>>>> Well specifically, it has to ask QEMU and QEMU can tell it the >>>>> current state via a nice structured data format over QMP. It's a >>>>> hell of a lot easier than the management tool trying to do this >>>>> outside of QEMU. >>>> >>>> So, if qemu crashes, the management tool has to start it up to >>>> find out what the current state is. >>> >>> Depends on how opaque we make the state file. I've been thinking a >>> simple ini syntax with a well supported set of keys. In that case, >>> a management tool can read it without starting QEMU. >> >> Then the management stack has to worry about yet another way of >> interacting via qemu. > > { 'StateItem': { 'key': 'str', 'value': 'str' } } > { 'StateSection': { 'kind': 'str', 'name': 'str', 'items': [ > StateItem' ] } } > { 'StateInfo': { 'sections': [ 'StateSection' ] } } > > { 'query-state', {}, {}, 'StateInfo' } > > A management tool never need to worry about anything other than this > command if it so chooses. If we have the pre-machine init mode for > 0.16, then this can even be used to inspect state without running a > guest. > > The fact that the state is visible in the filesystem is an > implementation detail. > >> I'd like to limit it to the monitor. >> >>>> >>>> Doesn't the stateful non-config file becomes a failure point? It >>>> has to be on shared and redundant storage? >>> >>> It depends on what your availability model is and how frequently >>> your management tool backs up the config. As of right now, we have >>> a pretty glaring reliability hole here so adding a stateful >>> "non-config" can only improve things. >> >> I think the solutions I pointed out close the hole with the existing >> interfaces. > > It doesn't work for eject unless you interpose an acknowledged event. > Ultimately, this is a simple problem. If you want reliability, we > either need symmetric RPCs so that the device model can call (and > wait) to the management layer to acknowledge a change or QEMU can post > an event to the management layer, and maintain the state in a reliable > fashion. > >>> >>>> To me, it seems a lot easier to require management to replay any >>>> commands that hadn't been acknowledged (due to management >>>> failure), or to query qemu as to its current state (if it is >>>> alive). >>> >>> You still have the race condition around guest initiated events >>> like eject. Unless you have an acknowledged event from a >>> management tool (which we can't do in QMP today) whereas you don't >>> complete the guest initiated eject operation until management ack's >>> it, we need to store that state ourself. >> >> I don't see why. >> >> If management crashes, it queries the eject state when it reconnects >> to qemu. >> If qemu crashes, the eject state is lost, but that is fine. My >> CD-ROM drive tray pulls itself in when the machine is started. > > Pick any of a number of possible events that change the machine's > state. We can wave our hands at some things saying they don't matter > and do one off solutions for others, or we can just have a robust way > of handling this consistently.
What machine state is to be preserved across crashes? Maybe I'm naive, but I can't think of anything but non-volatile device memory, e.g. disks, RTC CMOS, EEPROM. I can't quite see why we need conceptually different mechanisms for disks and all the rest. [...]