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

[Max Reitz <mreitz@redhat.com>]

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

On 2018-06-06 16:41, Dr. David Alan Gilbert wrote:
> * Max Reitz (mreitz@redhat.com) wrote:

[...]

>> 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;

That's how it always should be.  Life's tough, though.

>                                      it currently just works,

Due to sheer blind luck, I'd say.

>                                                               things
> should get better and easier for our users.

Users using a whole VM stack plus management, but then handling two
files instead of one is too much to ask?

>                                              And anyway, not working for
> EFI for exmaple can be just a blank screen.  Seriously - keep it easy
> for the user!

Thinking this through makes you end up with appliances.

> And with 'pc' type VMs being all that's around it does just-work.
> 

[...]

>>>>>> [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.

If they support the config format...

Max


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