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

[Michal Suchánek]

On Wed, 6 Jun 2018 10:36:20 -0500
Eric Blake <address@hidden> wrote:

> On 06/06/2018 10:05 AM, Dr. David Alan Gilbert wrote:
> 
> >   
> >>> We should make this EASY for users.  
> >>
> >> To me, having a simple config file they can edit manually certainly
> >> seems simpler than having to use specific tools to edit it inside
> >> of the qcow2 file.  
> > 
> > The users never touch the tools; they click and import the VM
> > image.  
> 
> And if we make it easy to import a tar file as the VM image, then
> that's still the case.
> 
> >> Sure that it isn't a soft constraint?  If most tools can stay
> >> unchanged but some very specific ones have to be changed, that
> >> seems reasonable to me.  
> > 
> > The hard constraint is the normal path stays unchanged; we can
> > change the tools to make use of the extra data, but not change
> > what's out there.  
> 
> But for the new config to be useful, you have to modify at least one 
> tool in the path.  At which point, it is just as easy to say:
> "libvirt is now smart enough to read the config file out of a .qcow2
> to know that it should prefer a q35 machine" as it is to say "libvirt
> is now smart enough to treat a .tar file containing .qcow2 and a
> config file that states that it should prefer a q35 machine", and
> either approach requires just a single file for the user to
> download.  Or, if you are worried about what happens in a too-old
> system that doesn't understand the config file, you have either: "the
> tool didn't know that the .qcow2 contained a config snippet, and
> tried to open the qcow2 file with pc even though q35 would have been
> better" or "the tool didn't know that the .tar file contains a config
> snippet and .qcow2 image, and could not run the image".  Either way,
> the image with the new config data doesn't run unless the user
> realizes they need to upgrade their system - but trying (and failing)
> to run is actually less friendly than flat out claiming unrecognized
> format and failing early.  So going with the tar format actually
> encourages users to upgrade, unlike going with enhancing qcow2.
> 

Yes, that's a good argument.

The reason why storing the config inside the qcow2 file is you have one
self-contained file that can be updated by qemu itself.

So you take an image file, point your management console to it, boot
it, change something on it, shut it down, and publish the image as the
new revision of the VM.

With the tar file the management console needs to chew the tar file,
save a copy of the config file and the disk image somewhere, and when
you update the image you have to re-export the tar file.

This is a lot of lengthy copying. The upside is that the console can
check that the machine you are exporting is not running an you are not
prone to publishing images in inconsistent state.

Thanks

Michal