* Max Reitz (mre...@redhat.com) wrote: > On 2018-06-06 13:37, Dr. David Alan Gilbert wrote: > > * Max Reitz (mre...@redhat.com) wrote: > >> On 2018-06-06 13:19, Michal Suchánek wrote: > >>> On Wed, 6 Jun 2018 13:02:53 +0200 > >>> Max Reitz <mre...@redhat.com> wrote: > >>> > >>>> On 2018-06-06 12:32, Michal Suchánek wrote: > >>>>> On Tue, 29 May 2018 12:14:15 +0200 > >>>>> Max Reitz <mre...@redhat.com> 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.
It's not a hack! Seriously it's not. There's nothing wrong with it being aimed higher up the stack than qemu, the problem we started off with was what happens when a user downloads a VM image and tries to import it into their VM system; weve already got 2+ layers of management stuff in there - I want the information to guide those layers, not form a complete set of configuration. > 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? Because we won't get it right; however much we bikeshed about it we'll just end up with a mess. The right thing is to put in something to hold configuration and then review the items of configuration we add properly as we define them. > 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. What makes it QEMU specific? It's basically just the same key/value setup as OVA, except putting them inside the qcow2. We could use the same keys/value definitions as OVA in the blob, although their definitions aren't very portable either. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
