On 2018-05-24 13:32, Richard W.M. Jones wrote:
> I read the whole thread and the fundamental problem is that you're
> mixing layers.  Let qcow2 be a disk image format, and let management
> layers deal with metadata and how to run qemu.
> 
> What's going to happen when you have (eg) an OVA file containing qcow2
> files, and the qcow2 files all have different metadata from each other
> and from the actual metadata in the OVA?  Even the case where you've
> got ‘-hda file1.qcow2 -hdb file2.qcow2’ is not properly defined.  What
> happens if someone uses ‘-M mach1 -hda file.qcow2’ and the machine
> type in the qcow2 file conflicts with the command line?
> 
> BTW we have a tooling (libguestfs) which can tell you what devices are
> supported by the guest.  virt-v2v already uses libguestfs to find out
> the full list of devices supported by guests, and uses that to drive
> conversion.  At some point we're going to extend virt-inspector to
> make this a bit easier (patches and other contributions welcome,
> there's a huge list of work to do on libguestfs and not enough
> developers to get through it).
> 
> There is however a seed of a good idea in the thread:
> 
>> I don't think QEMU needs to use this information automatically,
>> necessarily.  I think the first step is to simply make QEMU save
>> this information in the disk image, and making qemu-img able to
>> read and write this information.
> 
> It would be nice if qcow2 added arbitrary data sections (which would
> always be ignored by qemu) for storing additional data.  This could be
> used to create a compact qcow2 + metadata format to rival OVA for
> management layers to use, and there are various other uses too.

As an extremist on the "qcow2 is an image data format and as such should
only store data that is relevant to the virtual disk" front, I don't see
the appeal.

As someone who is just naive and doesn't see the big picture, I don't
see what's wrong with using a tar file that contains the image and
additional data.  I shudder to imagine integrating the qcow2 driver so
deeply into qemu that various parts all over qemu just use it to store
some data.  I can't help but feel reminded of the HMP savevm command
that just randomly chooses some qcow2 image to store the VM state in.

At least you're talking about just storing data.  I imagine opening a
qcow2 image, then reading some VM configuration, and spreading the
gospel through the rest of the qemu process to initialize everything
would be anything but nice.

I personally don't see why it is so bad to split the information between
two files.  Honestly, if you want to put disk images and VM
configuration into a single file, I'd do it backwards: Put the disk
image into the configuration file.

Max