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

[Max Reitz]

On 2018-06-06 17:25, Michal Suchánek wrote:
> On Wed, 6 Jun 2018 16:55:08 +0200
> Max Reitz <address@hidden> wrote:
> 
>> On 2018-06-06 16:41, Dr. David Alan Gilbert wrote:
>>> * Max Reitz (address@hidden) 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.
> 
> It's TimeProvenSolution(tm).
> 
>>
>>>                                                               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?
> 
> What you don't seem to realize is there are cases when there is an
> 'administrator' who has set up the VM stack plus management and 'joe
> user' who wants to run some random VM on that stack.
> 
> And if you download an appliance compatible with the stack it should
> just work. For a long time the 'appliance' for qemu based
> virtualization was a simple qcow2 file which was sized sufficiently for
> the VM to run but shrunk for transport. And although it is technically
> wrong it JustWorked(tm).

Hm, yes.  As I replied to Dave, I understand, but I would think this
then requires a real appliance solution.  I think you do want such a
solution, but Dave doesn't.

My problem is that I cannot accept Dave's arguments on why to include
this blob in qcow2 if someone else already plans on making that blob the
basis for qcow2 appliances.

And I still do not think that qcow2 is the right format for VM
appliances.  To convince me, we'd first need a consensus on what the
appliances are for (Michael seems to want them for qemu directly,
apparently you want them for something higher up the stack) and thus
what they are supposed to be capable of exactly.

Like, one thing that is important to discuss is this (but please not in
this thread...): If we agree on making an appliance format (qcow2 or
not), is it for running VMs off or do we just want it for VM
export/import?  The former might mean we need qcow2, because there is no
good way to offer good performance with multiple disks otherwise (but
this would constrain us e.g. in the disk image format -- no raw images
for you, then).  But the latter can work just fine with a normal
archival format as long as building/decomposing it is possible without
copying.

(I would think that you can move blocks from one file to another, so
with proper alignment you should be able to build/decompose an archive
from/into its members without copying.)

>>>                                              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 those can in general have more than one disk.

Indeed.  And thus knowing what we want is important so we can make a
good decision on where to store it instead of just focusing on where it
would be apparently simplest.

Max

signature.asc
Description: OpenPGP digital signature