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 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.
Max
signature.asc
Description: OpenPGP digital signature
