On 02/24/2011 07:58 PM, Anthony Liguori wrote:
If you move the cdrom to a different IDE channel, you have to update
the stateful non-config file.
Whereas if you do
$ qemu-img create -f cd-tray -b ~/foo.img ~/foo-media-tray.img
$ qemu -cdrom ~/foo-media-tray.img
the cd-rom tray state will be tracked in the image file.
Yeah, but how do you move it?
There is no need to move the file at all. Simply point the new drive at
the media tray.
If you do a remove/add through QMP, then the config file will reflect
things just fine.
If all access to the state file is through QMP then it becomes more
palatable. A bit on that later.
If you want to do it outside of QEMU, then you can just ignore the
config file and manage all of the state yourself. But it's never going
to work as well (it will be racy) and you're pushing a tremendous
amount of knowledge that ultimately belongs in QEMU (what state needs
to persist) to something that isn't QEMU which means it's probably not
going to be done correctly.
I know you're a big fan of the omnipotent management tool but my
experience has been that we need to help the management tooling folks
more by expecting less from them.
I thought that's what I'm doing by separating the state out. It's easy
for management to assemble configuration from their database and convert
it into a centralized representation (like a qemu command line). It's a
lot harder to disassemble a central state representation and move it
back to the database.
Using QMP is better than directly accessing the state file since qemu
does the disassembly for you (provided the command references the device
using its normal path, not some random key). The file just becomes a way
to survive a crash, and all management needs to know about is to make it
available and back it up. But it means that everything must be done via
QMP, including assembly of the machine, otherwise the state file can
become stale.
Separating the state out to the device is even easier, since management
is already expected to take care of disk images. All that's needed is to
create the media tray image once, then you can forget about it completely.
Again the question is who is the authoritative source of the
configuration. Is it the management tool or is it qemu?
QEMU. No question about it. At any point in time, we are the
authoritative source of what the guest's configuration is. There's no
doubt about it. A management tool can try to keep up with us, but
ultimately we are the only ones that know for sure.
We have all of this information internally. Just persisting it is not
a major architectural change. It's something we should have been doing
(arguably) from the very beginning.
That's a huge divergence from how management tools are written.
Currently they contain the required guest configuration, a
representation of what's the current live configuration, and they issue
monitor commands to move the live configuration towards the required
configuration (or just generate a qemu command line). What you're
describing is completely different, I'm not even sure what it is.
The management tool already has to keep track of (the optional parts
of) the guest device tree. It cannot start reading the stateful
non-config file at random points in time. So all that is left is the
guest controlled portions of the device tree, which are pretty rare,
and random events like live-copy migration. I think that introducing
a new authoritative source of information will create a lot of problems.
QEMU has always been the authoritative source. Nothing new has been
introduced. We never persisted the machine's configuration which meant
management tools had to try to aggressively keep up with us which is
intrinsically error prone. Fixing this will only improve existing
management tools.
If you look at management tools, they believe they are the authoritative
source of configuration information (not guest state, which is more or
less ignored).
Right, but we should make it easy, not hard.
Yeah, I fail to see how this makes it hard. We conveniently are
saying, hey, this is all the state that needs to be persisted. We'll
persist it for you if you want, otherwise, we'll expose it in a
central location.
The state-in-a-file is just a blob. Don't expect the tool to parse it
and reassociate the various bits to its own representation. Exposing it
via QMP commands is a lot better though.
If the tool wants to ignore it and guess based on various combinations
of other commands, more power to it.
I don't see why it doesn't work. Please explain.
1) guest eject
2) qemu posts eject event
3) qemu acknowledges eject to the guest
4) management tool sees eject event and updates guest config
There's a race between 3 & 4. It can only be addressed by
interposing 4 between 2 and 3 OR making qemu persist this state
between 2 and 3 such that the management tool can reliably query it.
If "it" is my cd-rom tray block format driver, it works. It's really
the same in action as the stateful non-config, except it's part of
the device/image, not a central location.
Because you've introduced a one-off. Having a bunch of one-offs
(especially being a bunch of new block formats!) is not going to make
things simpler for management tools.
I don't see it as a one-off. We have some state, we store it in a state
file. Like we store each image in its own file.
Have a tool expose it. Part of the range is unspecified anyway.
I guess we need to agree to disagree then.
We can just extend our existing disagreement agreement.
Using a block format driver means that we don't have to care about a
crash during a write, that we can snapshot it, etc.
Why?
Because block format drivers are already prepared for it.
We always need to care about a crash during write. What I've been
thinking for a config file is the class approach of using a ~ and .#
file to make sure that we write out the new file and then atomically
rename it to get the new contents. Yeah, it's a bit heavy weight but
this shouldn't be a very common thing to update.
Suppose it has information about ide1-cd0's media tray. Now we
restart qemu and cold-plug the cdrom into ide0-cd0. What happens to
the information?
Whether media is present is not a property of a blockdev, it's a
property of a device.
You're making it the property of a device path (I guess you could make
it the property of a device's id).
What does it even mean to use your media-tray format with something
like a CMOS device?
Nothing.
Technically, mac address is stored on eeprom and we store that as a
device property today. We can't persist device properties even
though you can change the mac address of a network card and it does
persist across reboots. Are you advocating that we introduce an
eeprom for every network card (all in a slightly different format)
and have special tools to manipulate the eeprom to store and view
the mac address?
Yes -- if we really want to support it. Obviously we have to store
the entire eeprom, not just the portion containing the MAC address,
so it's not just a key/value store. A card may even have its firmware
in flash.
I think that's overengineering. I think we can go very far by just
persisting small amounts of information in a central location. We're
not building a cycle-accurate simulator here afterall.
Well, the whole thing is rather theoretical.