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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> On Wed, 2018-06-06 at 17:32 +0100, Daniel P. Berrangé wrote:
> > On Wed, Jun 06, 2018 at 10:36:20AM -0500, Eric Blake wrote:
> > > 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.
> 
> Something that I haven't seen mentioned in the thread - and this
> looks like as good a point as any to jump in - is that for q35
> guests using EFI as well as aarch64 guests the "one click import"
> experience requires not only hints about the machine (and firmware!)
> type, but also a copy of the EFI variable store:
> 
>   $ virt-builder fedora-27 --arch aarch64 --notes
>   Fedora® 27 Server (aarch64)
> 
>   [...]
> 
>   You will need to use the associated UEFI NVRAM variables file:
>     http://libguestfs.org/download/builder/fedora-27-aarch64-nvram.xz
> 
> While hints might be considered a reasonable fit for qcow2, I think
> it's pretty hard to argue for embedding the NVRAM file in there,
> which to me signals quite clearly that an archive containing the
> disk image(s) *and* the configuration hints *and* other ancillary
> files such as the NVRAM is the only way to build a solution that's
> not dead on arrival.

On a similar theme, I can imagine users wanting to provide a TPM
data blob too, and for AMD SEV we'd need to be able to provide a
DH key, and session blob too IIUC.

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