Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]

[Mark McLoughlin]

On Fri, 2009-06-12 at 09:51 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> >   
> >> Michael S. Tsirkin wrote:
> >>     
> >>>> I think the right long term answer to all this is a way to get QEMU to
> >>>> dump it's current machine configuration in glorious detail as a file
> >>>> which can be reloaded as a machine configuration.
> >>>>         
> >>> And then we'll have the same set of problems there.
> >>>       
> >> We will, and the solution will be the same: options to create devices
> >> as they were in older versions of QEMU.  It only needs to cover device
> >> features which matter to guests, not every bug fix.
> >>
> >> However with a machine configuration which is generated by QEMU,
> >> there's less worry about proliferation of obscure options, compared
> >> with the command line.  You don't necessarily have to document every
> >> backward-compatibility option in any detail, you just have to make
> >> sure it's written and read properly, which is much the same thing as
> >> the snapshot code does.
> >>     
> >
> > This is a sensible plan, but I don't think we should mix these compat
> > options in with the VM manager supplied configuration.
> >
> > There are two problems with that approach.
> >
> > = Problem 1 - VM manager needs to parse qemu config =
> >
> > Your proposal implies:
> >
> >   - VM manager supplies a basic configuration to qemu
> >
> >   - It then immediately asks qemu for a dump of the machine 
> >     configuration in all its glorious detail and retains that
> >     config
> >
> >   - If the VM manager wishes to add a new device it needs to parse the 
> >     qemu config and add it, rather than just generate an entirely new 
> >     config
> >   
> 
> What's the problem with parsing the device config and modifying it?  Is 
> it just complexity?

Yes, complexity is the issue.

> If we provided a mechanism to simplify manipulating a device config, 
> would that eliminate the concern here?

In libvirt's case, a lot of the complexity would come from needing to
figure out what to change.

i.e. libvirt produces a qemu configuration (currently a command line)
from a guest XML's configuration; with this idea, libvirt would probably
compare the old XML config to the new XML config, and then apply those
differences to the qemu configuration.

Cheers,
Mark.