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

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

On 2018-06-06 16:43, Michael S. Tsirkin wrote:
> On Wed, Jun 06, 2018 at 01:02:53PM +0200, Max Reitz wrote:
>> Yeah, but why make qcow2 that format?  That's what I completely fail to
>> understand.
> 
> Because why not? It's cheap to add it there and is much easier
> than teaching people about a new container format.

"new" container format?  qcow2 is not a container format, so that would
be teaching people something new anyway.

> Eric Blake put it very well I think.  There are several things that
> several people would like to see addressed:
> 
> (1) A sensible list of guest visible aspects of the VM
>   preserving which across VM restarts we deem critical enough to support
>   starting guests.
>   At this point this includes at least architecture and machine type.

If you use a whole management layer, that is trivial anyway (and that
seems to be Dave's assumption), because that management layer can store
its configuration somewhere.  Dave's issue was about downloading foreign
images, not about restarts.

> (2) A compact file format for serializing list (1)

OK.

> (3) Ability to store file (2) in a qcow2 image

I see that people are asking this, yes, although I don't quite get the
point.

> You are asking why store (2) in qcow2 image specifically. The answer is
> it's just one place where we can store it. The answer is we don't need
> to involve qemu-block at all for storing it in other places.
> 
> But for many people it will be handy to have it in the same file, and
> qcow2 is popular enough that many people will be well served if it's
> there.

Note that I'm also asking why it needs to be a single file.
Furthermore, I'm asking what the final scope is intended to be.  I don't
believe qcow2 to be the correct format for a whole appliance, but I do
believe that assuming that people want to provide just a qcow2 file
without anything else means already accepting it *is* an appliance.  But
Dave seems to reject that idea.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]