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

[Max Reitz]

On 2018-06-06 13:37, Dr. David Alan Gilbert wrote:
> * Max Reitz (address@hidden) wrote:
>> On 2018-06-06 13:19, Michal Suchánek wrote:
>>> On Wed, 6 Jun 2018 13:02:53 +0200
>>> Max Reitz <address@hidden> wrote:
>>>
>>>> On 2018-06-06 12:32, Michal Suchánek wrote:
>>>>> On Tue, 29 May 2018 12:14:15 +0200
>>>>> Max Reitz <address@hidden> wrote:

[...]

>>>>>> Unless I have got something terribly wrong (which is indeed a
>>>>>> possibility!), to me this proposal means basically to turn qcow2
>>>>>> into (1) a VM description format for qemu, and (2) to turn it into
>>>>>> an archive format on the way.  
>>>>>
>>>>> And if you go all the way you can store multiple disks along with
>>>>> the VM definition so you can have the whole appliance in one file.
>>>>> It conveniently solves the problem of synchronizing snapshots across
>>>>> multiple disk images and the question where to store the machine
>>>>> state if you want to suspend it.   
>>>>
>>>> Yeah, but why make qcow2 that format?  That's what I completely fail
>>>> to understand.
>>>>
>>>> If you want to have a single VM description file that contains the VM
>>>> configuration and some qcow2/raw/whatever files along with it for the
>>>> guest disk data, sure, go ahead.  But why does the format of the whole
>>>> thing need to be qcow2?
>>>
>>> Because then qemu can access the disk data from the image directly
>>> without any need for extraction, copying to different file, etc.
>>
>> This does not explain why it needs to be qcow2.  There is absolutely no
>> reason why you couldn't use qcow2 files in-place inside of another file.
> 
> Because then we'd have to change the whole stack to take advantage of
> that.  Adding a feature into qcow2 means nothing else changes.

Because it's a hack, right.  Storing binary data in a qcow2 file,
completely ignoring it in qemu (and being completely unusable to any
potential other users of the qcow2 format[1]) and only interpreting it
somewhere up the stack is a hack.

That is not necessarily a negative point, hacks can work wonderfully
well, and they usually are simple, that is correct.  But the thing is
that I feel like people have grand visions of what to get out of this.
Imagine, a single file that can configure all and any VM!

But hacks usually only solve a single issue.  Once you try to extend a
hack, it breaks down and becomes insufficient.

If we want a grand vision where a single file stores the whole VM, why
not invest the work and make it right from the start?

Max

[1] Yes, I concede that there are probably no other users of qcow2.  But
please forgive me for assuming that qcow2 was in a sense designed to be
a rather general image format that not only qemu could use.

signature.asc
Description: OpenPGP digital signature