Re: [Qemu-devel] [PATCH] qcow3 - arbitrary metadata

[Nathaniel McCallum]

On Mon, Jul 28, 2008 at 10:11 PM, Jorge Lucángeli Obes <address@hidden> wrote:

On Mon, Jul 28, 2008 at 10:49 PM, Jamie Lokier <address@hidden> wrote:
> Anthony Liguori wrote:
>> Can you provide more information about what the metadata is used for and
>> why it's so important for the metadata to be in the image verses in a
>> separate file?
>
> Yeah, I have the opposite problem - too much in the same file :-)
>
> I want to be able to savevm, but some of my VMs don't have any qcow2
> images (because I don't trust them for mission-critical VMs since
> recent discussion, or because they are floppy-only or CD-only VMs with
> no hard disk).
>
> To enable savevm, at least according to docs, I have to have a qcow2
> image somewhere.  So I add a redundant minimum-size unpartitioned
> qcow2 hard disk and hope nobody minds...
>
> That seems a bit hackish.  It would be nice if savevm could just write
> to a named file and loadvm could read it.

I think this brings us to the main conceptual point of the discussion:
what does an image file represent? I am now partial to the idea that
an image file is nothing more than the representation of some kind of
storage device. It's not meant, IMHO, to be the representation of an
entire machine.

As Laurent pointed out, he and I proposed and coded a (quite hackish)
way of storing command-line options in qcow2 image files, which used
empty qcow2 snapshots. This was Avi's original suggestion to make
image files self-contained. The goal of this approach was to have a
quick and easy way to avoid the QEMU command-line. The use case was to
replace launch scripts, not to replace tools as libvirt and
virt-manager. A lengthy discussion followed the patches and my
conclusion was that there were many valid objections to our approach,
but more than that, there were many strong opinions on what the best
way to achieve this was.

I remember Anthony Liguori proposing another way of having
self-contained images, though I don't remember the particulars of his
approach right now. As Laurent also mentions, Fabrice has proposed a
configuration file format which I think is a good way of solving the
problem. Personally, I just want to have some way of avoiding the
command-line options that doesn't involve scripts.

Anyways, the point that I was trying to make was that a good solution
would separate concerns: the image file is the disk, the configuration
file (in this case) represents the machine. Looking back, I think that
storing command-line options in an empty qcow2 snapshot was a quick
hack, without much conceptual integrity. I won't deny it, thought, it
was extremely useful.

As Jamie exemplifies, storing everything in the image file can be
inflexible for some use cases. IMHO, a "virtual appliance" format
would bundle an image file and some other configuration files, but
that would possibly not be a part of QEMU itself.

I'm not disagreeing, but it is really interesting that something that is "extremely useful" is rejected for lacking "conceptual integrity".  I don't have any numbers, but I suspect the most common use case of virtualization is one image file, one configuration and no snapshots.  Yet most virtualization solutions go for those designs which have "conceptual integrity" but are far more complex than needed by the majority of users (*cough*VMWare API*cough*).  I think those features are important and I don't want to cut them.  I just think there should be some way to optimize the user experience for the most common case without sacrificing the rest of the features.

Nathaniel