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

[Daniel P . Berrangé]

On Wed, Jun 06, 2018 at 10:36:20AM -0500, Eric Blake wrote:
> 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.

Just to be clear, libvirt isn't going to do either of those things.

Whether there is metadata stuffed inside qcow2, or in a metdata file
inside a tar file, libvirt is not going to look inside either of them.
The XML is the only place libvirt deals with the hardware config.

Extracting machine type is always going to be a job for the layer above
such as OpenStack/OVirt/Virt-manager/etc. They will then decide whether
or not they want to honour that info, and if so, put it into the XML
they give to libvirt.

As mentioned elsewhere, IMHO, it is more friendly to those tools
to use pre-existing formats, eg TAR and XML/JSON, for which
their respective programming langauges already have APIs/parsers.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|