Re: [Qemu-devel] storing machine data in qcow images?

["Richard W.M. Jones" <rjones@redhat.com>]

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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW