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

[Eric Blake]

On 06/06/2018 10:05 AM, Dr. David Alan Gilbert wrote:

> > If that's the issue, add a UUID to qcow2 files and reference it from the
> > config file.
>
> Is a UUID a small string :-)

Even better, it's something that you could stick directly in the qcow2 
header (and which therefore cannot grow to a larger size) - it would be 
a well-constrained scoped addition.  Maybe the analogy to actual 
hardware would be that the config file is like a sticky note, and a UUID 
embedded in the qcow2 file would be the disk serial number; if you are 
paranoid that the sticky note could be too easily pulled off one disk 
and put on another, then the sticky note can include the serial number.

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


> Because it's got to be EASY for the customer; seriously - stop punishing
> the user for not noticing something.
> We've got to help the users, if not we get people asking why their VM
> system has given them a black screen, or why the image they just
> downloaded didn't work - it's basic user friendliness.
>
> It's not obvious why it's failed; if it was as simple as a nice box
> popping up telling them they'd booted it wouldn't be too bad; but some
> of them will waste 3 hours trying to figure out wth happened.
>
> *seriously* think about our users.

I am - to me, telling a user that "here is your image, it is a new file 
extension, therefore you need a new qemu before you can even try to use 
it - but once you have that, everything just works" is nicer than "here 
is the same extension you've always used, but it might not work for you 
and it might be 3 hours of your time to figure out why it didn't work".

> > The implementation is trivial is what I meant, just like the
> > implementation would be rather simple for qcow2 to store a binary blob
> > and completely ignore it.
>
> But then you'd have people shipping .newformat files as well as qcow2
> files and you'd have to persuade people to start doing that, and they'd
> ship both or none or....

Why would you intentionally ship a .qcow2 that only works on q35 if 
.newformat is already known to be nicer to users?  Just ship .newformat! 
 People shipping just .qcow2 would be limited to those used to 'pc' as 
the default, but even they could be encouraged to tweak their process to 
make it easier for end consumers to take advantage of .newformat.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org