Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy

[Avi Kivity]

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.

--
error compiling committee.c: too many arguments to function