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

[Richard W.M. Jones]

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.

> 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