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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Richard W.M. Jones (rjones@redhat.com) wrote:
> On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> > 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
> 
> This is true, although only sometimes.  If the bootloader[*] has a
> working fallback path then usually it is able to boot and reset the
> UEFI varstore back to the correct values.  We have had bugs before
> where the fallback path was not working, eg:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1353689 (yours!)
>   https://bugzilla.redhat.com/show_bug.cgi?id=1558793
> 
> Another problem which Laszlo mentioned is the varstore isn't portable
> between UEFI implementations, or if the UEFI is compiled with
> different options.  You can even imagine shipping multiple
> varstores(!) which argues for a tar-like format.

Given that level of incompatibility with var stores (which I've seen
myself) I don't see how you can distribute them with images.

Dave

> > 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.
> 
> The tar argument is quite strong.  Just not the wretched OVA/OVF :-)
> 
> > It's pretty easy then to imagine using something like
> > 
> >   $ virt-builder \
> >     fedora-27 \
> >     --arch aarch64 \
> >     --format qva \
> >     --output f27-aarch64.qva
> > 
> > or download the equivalent from some website, followed by
> > 
> >   $ virt-install \
> >     --name f27-aarch64 \
> >     --import \
> >     --input f27-aarch.qva
> > 
> > or the equivalent pointy-clicky import step and having things
> > Just Work™, provided sufficient hints are included in the archive;
> > the user, or the management application, would of course be able
> > to override such hints at import time.
> 
> RFEs for virt-builder & virt-install one day :-)
> 
> Rich.
> 
> [*] I'm not sure exactly which bit of the bootloader does this,
> whether it's UEFI itself, or the grub-efi in the guest.
> 
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK