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

[Max Reitz <mreitz@redhat.com>]

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

On 2018-06-06 18:10, Eduardo Habkost wrote:
> On Wed, Jun 06, 2018 at 04:17:14PM +0200, Max Reitz wrote:
>> On 2018-06-06 15:45, Michal Suchánek wrote:

[...]

>>> I understand that for some use cases simplifying the distribution of
>>> VMs as much as possible is quite important.
>>
>> I don't because still nobody has explained it to me.
>>
>> The only explanation I got so far was "People are lazy and we have
>> defaults for everything, so we don't throw an error if people forget to
>> pass a configuration file."
> 
> People don't pass a configuration file today because there's no
> standard for such a configuration file.  qcow2 is already used
> today as an appliance file format because there's no better
> option.  People download disk images from appliance and OS
> providers, import them into a cloud system, and it works out of
> the box because (luckily) "pc" is enough for most of them.

OK.

> We can specify a true appliance file format, and ask people to
> use it.  But then providers of single-disk appliances and OSes
> will need to publish two appliance images: qcow2 disk image for
> old systems that don't support the new format, and one in the new
> appliance format, for systems that support it.

True.  This is a valid argument for making a compatible change to qcow2.
 But: If these options are actually important, the qcow2 file is not
really compatible either.  You might end up with a blank screen again.

Depending on how we'd design a new format, it might contain a config
file and a qcow2 file which may be easily extractable.  If so, users of
legacy software could easily extract the qcow2 file and might even be
tempted to look at the config file when it doesn't work, and maybe that
could even help them.

Also, I think that it is not too unreasonable to ask providers to
provide two formats.

But that does not make me disregard your argument.  It is still valid,
especially with your convenience note below.

(Providers could choose whether it is best for them to include the
description in the qcow2 file, or whether to offer an archive that
contains e.g. a raw file.)

>> Which to me still just makes it an inconvenience.
> 
> Well, there are small inconveniences and there are big
> inconveniences that together make a system unnecessarily hard to
> use.  I'd say this one falls somewhere in the middle.

Hm, OK.

> [...]
>> I'm noticing a pattern here, and that is that everybody has a different
>> opinion on what we actually want in the end, and it's just by chance
>> that we find ourselves in two camps ("put it in qcow2" vs. "put it
>> somewhere else").
>>
>> Maybe we should first discuss what we actually want before we can
>> discuss where to put it.
> 
> I'm inclined to agree.  Once we figure out a good VM description
> format, we can justify a proposal to allow embedding the VM
> description in qcow2 for convenience.

OK.

Max


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