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