On Wed, Jun 06, 2018 at 13:02:56 +0200, Max Reitz wrote:
> On 2018-06-05 11:21, Dr. David Alan Gilbert wrote:

[...]

> >       (I would suggest in layer2 that the keys are sorted, but
> >       that's a pain to do in some json creators)
> >    c) Forcing the registry of keys might avoid silly duplication.
> >       We can but hope.
> >    d) I've not said it's a libvirt XML file since that seems
> >       a bit prescriptive.
> > 
> > Some initial suggested keys:
> > 
> >    "qemu.machine-types": [ "q35", "i440fx" ]
> >    "qemu.min-ram-MB": 1024
> 
> I still don't understand why you'd want to put the configuration into
> qcow2 instead of the other way around.
> 
> Or why you'd want to use a single file at all, because as this whole
> thread shows, a disk image alone is clearly not sufficient to describe a VM.

I concur to many points made here. I think it would be wrong to put
anything besides disk-related data in a disk image.

If we want to have a all-in-one VM image, then it should be something
separate from this.

Some more points against squashing all this irrelevant stuff into qcow2
is that if you use it as a disk image only with any higher level
management you don't care about any stored configuration.

In fact in libvirt we'd need a way to prevent any of the data from the
disk image from  being applied to the configuration as it would create
problems.

Also there is a big difference between storing "suggestions" of
configuration and the actual full configuration itself. The
"suggestions" which storage controller or machine type to use are
sometimes helpful and sometimes not. Users may have their own
preference. And besides this we have the libosinfo project which can
provide suggestions.

I think that if the clear separation between a disk image format and an
all-in-one VM file is not kept it will end up in a big mess.