* Max Reitz (mre...@redhat.com) wrote: > On 2018-06-06 16:02, Dr. David Alan Gilbert wrote: > > * Max Reitz (mre...@redhat.com) wrote: > >> On 2018-06-06 14:16, Dr. David Alan Gilbert wrote: > >>> * 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, > >> > >> Not really, but storing that information in a disk image file is, from > >> my perspective. So far, qcow2 was always just for qemu. (Hmm... Maybe > >> backing links weren't, but at least they were intended for qemu > >> originally.) > >> > >> So this would mix information for different layers inside qcow2 which to > >> me sounds weird. Maybe I just have to get used to it. > > > > The important point is it's explicitly for a different layer; we're not > > mixing it - the guest can never get to this information. > > Neither can it get to bitmaps, but bitmaps are still for qemu. > > > It also saves > > the higher level management layers ever having to look at the data the > > guest can get to, which is a security advantage. > > Er, well, yes, but guessing configuration options from the guest disk > contents is definitely a bad idea, I agree on that anyway. > > > From my point of view, it really is the sticky label on the disc rather > > than the contents of it. > > Sure, which is why I wouldn't put it in qcow2. Content and meta-content > is what qcow2 currently stores, but not how to use it. > > >>> 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; > >> > >> Well, the VM system should choke without a config file. O:-) > >> > >>> 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. > >> > >> But I do. > >> > >> If we store some information, I don't see why we don't store all of it. > > > > Hmm, now that generally I don't like: > > Me neither. > > > a) That really would make it hypervisor specific > > Yes. > > > b) It would be a lot of data > > Yes. > > > c) Generally, the supplier of an image doesn't know how the end-user > > wants it configured - although for some appliances they might. > > Well, yes. But just storing very basic information limits the use case > to a very basic case anyway, doesn't it? So this wouldn't be worse. > > Everything beyond a very basic use case can expect the user to take 30 > seconds to download and pass a config file. > > > d) Remember the only problem we had when we got here was how to stop > > the user shooting themselves in the foot by connecting the wrong > > image to the wrong VM type. > > Hm. How exactly is that shooting yourself in the foot? Won't it just > not work? > > > So I'm expecting to use this to > > contain requirements, nothing more. > > I assumed you'd want to relieve users of having to specify config > options in basic use cases. This is why I believed it would be natural > to expand that scope. > > So why is it so dangerous to connect a disk you just downloaded to e.g. > the wrong machine type? I assumed it just wouldn't work and you'd try > again, until you realized that maybe you should read the download > description and do as it says ("download this config file, pass it").
That's bad! Stuff should just-work; it currently just works, things should get better and easier for our users. And anyway, not working for EFI for exmaple can be just a blank screen. Seriously - keep it easy for the user! And with 'pc' type VMs being all that's around it does just-work. > >>>> 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. > >> > >> Sure, but the same thing applies to putting it into qcow2. The > >> difference is, for something outside of qcow2, throwing it away and > >> starting over is simple. > >> > >> When putting it into qcow2, we can only do that if we really just put a > >> binary blob there that isn't described in the specification. > > > > Well, it's why I'm going for defined key/values that are stored in the > > blob and only a few of them. We've got a reasonable chance of being > > able to define what we want from 3-4 key/values, it should be a lot > > easier than trying to define a grand scheme. > > Yes, as long as we can agree on how we can justify to future generations > why we really only want these very few very specific values. > > >>> 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. > >> > >> OK, but review them on what terms? Whether they are simple enough? > > > > Well, I'll take simple, make sense - whatever - feel free to be the > > maintainer for that list! > > OK, none. :-P > > It would need to be a very strict requirement, in any case. Just > "simple" or "dense" do not suffice, because those can be stretched. > > >> As I said, I would want a whole configuration if we allow some > >> configuration. > > > > Well then you could go for libvirt XML as the contents; but I think > > that's crossing layers even more. > > (I would have veered more to it being exactly the same as an OVA > > description except for rjones dislike of it) > > Well, the format doesn't really matter for now, I think it's most > important to first talk about what kind of scope we want. > > >> (More below) > >> > >>>> [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. > >> > >> Well, not necessarily qemu-specific, but > >> ${management_software}-specific, which comes down to the same. Or, > >> well, I'd think that, but hold on. > >> > >>> We could use the same keys/value definitions as OVA in the blob, > >>> although their definitions aren't very portable either. > >> > >> So you're proposing that we only add options that seem portable for any VM? > > > > Hmm. We should probably split them, so there should be general options > > (e.g. minimum-ram) but also hypervisor specifics > > (qemu.machine-class=q35); but that doesn't mean you can't add keys > > for multiple hypervisors into the one blob. I mean > > something like: > > minimum-ram = 1G > > qemu.machine-class = q35 > > anothervm.machine-class = .... > > Well, and that's my issue. Once you have application-specific info, you > can go wild. And I would go wild, without a reasonable and strict > requirement that the information we want to store has to fulfill. > > For the record, I would've liked it if you'd said "only portable > options". But I would have replied that I would fear we'd still end up > with someone saying "I'd like to store X and Y, let's just put them into > the specification, then they are portable [even if only this stack > supports them]" and we wouldn't really have won anything. I couldn't second guess every other hypervisor on the planet to know whether specifying a machine class would work for them. Dave > Max > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK