* Daniel P. Berrangé (berra...@redhat.com) 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 / dgilb...@redhat.com / Manchester, UK