On Wed, Feb 23, 2011 at 02:18:31PM -0600, Anthony Liguori wrote: > 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. > > >> > >>I don't like the idea of making a management tool such an > >>integral part of the functional paths. > > > >I agree that we don't want qemu to wait on the management stack > >any more than necessary. > > > >>Not having a stateful config file also means that this problem > >>isn't solved in any form without a really sophisticated > >>management stack. I'm a big fan of being robust in the face of > >>not-so sophisticated management tools. > > > >You're introducing the need for additional code in the management > >layer, the care and feeding for the stateful non-config file. > > If a management layer ignores the stateful non-config file, as you > like to call it, it'll get the same semantics it has today. I think > managing a single thing is a whole lot easier than managing an NVRAM > file, a block migration layering file, and all of the future things > we're going to add once we decide they are important too. > > >>>If qemu crashes, these events are meaningless. If management > >>>crashes, it has to query qemu for all state that it wants to > >>>keep track of via events. > >> > >>Think power failure, not qemu crash. In the event of a power > >>failure, any hardware change initiated by the guest ought to be > >>consistent with when the guest has restarted. If you eject the > >>CDROM tray and then lose power, its still ejected after the > >>power comes back on. > > > >Not on all machines. > > > >Let's list guest state which is independent of power. That would > >be wither NVRAM of various types, or physical alterations. CD-ROM > >eject is one. Are there others? > > Any indirect qemu state. Block migration is an example, but other > examples would be VNC server information (like current password), > WCE setting (depending on whether we modelled eeprom for the > drivers), and persisted device settings (lots of devices have eeprom > these days).
Agreed. Why a separate location for this "stateful non-config" section, however? The state in question (backing image property, device presence, VNC info, etc) is already represented in either host or guest configuration, so why not simply expose that?