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

["Michal Suchánek" <msuchanek@suse.de>]

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

On Wed, 6 Jun 2018 20:02:54 +0200
Max Reitz <mreitz@redhat.com> wrote:

> On 2018-06-06 17:25, Michal Suchánek wrote:
> > On Wed, 6 Jun 2018 16:55:08 +0200
> > Max Reitz <mreitz@redhat.com> wrote:
> >   
> >> On 2018-06-06 16:41, Dr. David Alan Gilbert wrote:  
> >>> * Max Reitz (mreitz@redhat.com) wrote:    

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

Yes, Dave wants a poor man's half-assed appliance and insists on it not
being an appliance. Duh.

In the pc world to maintain the status quo with minimum changes you
only need to know if the image uses EFI or legacy BIOS and you can
maintain the illusion that the TimeProvenSolution(tm) JustWorks(tm).

Sneaking that single piece of information somewhere seems to be the
goal here.

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

Let's put this straight: qemu as is cannot run appliances. It is not
designed for that and it would be a big feature to create enough
management inside qemu (or around qemu but part of qemu distribution) to
change that.

As it stands qemu always takes the configuration from the outside -
either from the user directly or from a separate management layer.

> apparently you want them for something higher up the stack) and thus
> what they are supposed to be capable of exactly.

Using qcow2 would be kind of cool but it has its limitations and
drawbacks as well.

You could use qcow2 as transport format and convert the VM to use
raw disks or whatever if you need the performance. And you could run
the VM directly from qcow2 without additional processing which is its
advantage.

It would fail miserably with tools not aware of the extra metadata,
however.

Lastly we are missing a developer of a management layer committed to
support such appliances.

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

Indeed, using an archive should be good enough for the 1-click download
solution. It will take time to extract but it will typically take even
more time to download or publish. So optimizing the format for speed of
export/import might be misplaced.

Thanks

Michal

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