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

[Dr. David Alan Gilbert]

* Daniel P. Berrangé (address@hidden) wrote:
> 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.

Libvirt could provide a wrapper around whichever format to extract the
data and provide it to the upper layer.  It could also validate against
it to see if the constraints were met as a service for an upper layer.

Dave

> 
> 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 :|
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK