On 02/23/2011 10:18 PM, Anthony Liguori wrote:
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.
So we have yet another information tree. If we store the cd-rom eject
state here, then we need to make an association between the device path
of the cd-rom, and the StateItem key.
Far better to store it in the device itself. For example, we could make
a layered block format driver that stores the eject state and a "backing
file" containing the actual media. Eject and media change would be
recorded in the block format driver's state. You could then hot-unplug
a USB cd-writer and hot-plug it back into a different guest,
implementing a virtual sneakernet.
The fact that the state is visible in the filesystem is an
implementation detail.
A detail that has to be catered for by the management stack - it has to
provide a safe place for it, back it up, etc.
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.
I don't see why it doesn't work. Please explain.
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.
Both block live copy and cd-rom eject state can be solved with layered
block format drivers. I don't think a central place for random data
makes sense. State belongs near the device that maintains it, esp. if
the device is hot-pluggable, so it's easy to associate the state with
the device.
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.
I disagree. Storing NVRAM as a disk image is a simple extension of
existing management tools. Block live-copy and cd-rom eject state also
make sense as per-image state if you take hotunplug and hotplug into
account.
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).
Device settings should be stored with the devices, not with qemu.
Suppose we take the cold-plug on startup via the monitor approach. So
we start with a bare machine, cold plug stuff into it. Now qemu has to
reconcile the stateful non-config file with the hardware. What if
something has changed? A device moved into a different slot?
If a network card has eeprom, we can specify it with -device
rtl8139,eeprom=id, where id specifies a disk image for the eeprom.
I think my solution (multiplexing block format driver) fits the
requirements for live-copy perfectly. In fact it has a name - it's a
RAID-1 driver started in degraded mode. It could be useful other use
cases.
It feels a bit awkward to me to be honest.
Not to me.
--
error compiling committee.c: too many arguments to function
