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

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

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Fri, Jun 08, 2018 at 09:21:30AM +0100, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (lersek@redhat.com) wrote:
> > > On 06/07/18 12:54, Andrea Bolognani wrote:
> > > > On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrangé wrote:
> > > >> On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote:
> > > >>> 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.
> > > >>
> > > >> Could we perhaps imagine shipping the actual UEFI bios, rather
> > > >> than only the varstore.  The bios blob runs in guest context,
> > > >> so there shouldn't be able security concerns from hosting
> > > >> vendors with running user provided bios. Mostly its a matter
> > > >> of confidence that the interface between bios & qemu is stable
> > > >> which feels easier than assuming varstore vs different bios is
> > > >> portable.
> > > > 
> > > > That sounds sensible, and further reinforces the idea that we
> > > > need way more than a single string baked into the qcow2 file.
> > > > 
> > > 
> > > Sorry for arriving late (thanks Rich for the Fwd).
> > > 
> > > The contents of the non-volatile UEFI variables should be considered
> > > part of (permanent) guest state, such as disk contents. Therefore I'd
> > > argue for bundling the varstore file with the disk image(s).
> > > 
> > > In turn, the best way to ensure comaptibility between varstore and
> > > firmware binary is to just bundle the firmware binary as well. It's
> > > generally not large (x86) or if it is, it compresses extremely well
> > > (aarch64). For extra politeness, image providers can bundle a text file
> > > with their firmware build options (like a kernel config), possibly even
> > > a JSON document conforming to the new firmware schema (qemu commit
> > > 3a0adfc9bfcf), but that's not a hard requirement I guess.
> > > 
> > > If such a VM is to be migrated between hosts, I'd expect the host admin
> > > to take care of installing the fw binary on all eligible hosts.
> > 
> > There's no way they can do that if they're just importing VMs from
> > templates that include the image; who is going to keep track of which
> > BIOSs are needed where?
> 
> It isn't that unusual a requirement. When Openstack deploys a VM, it
> has the user provided image as a base file, and then creates  qcow2
> overlay.  If the VM is cold migrated (ie not running) to another
> host, OpenStack has to make sure the same base file gets copied across
> to the new host so that the overlay still works. Copying the BIOS file
> and vars state across at the same time is no more difficult than what
> its already doing.

I'm kind of OK with management layers doing it; but Laszlo was
suggesting it was an admins problem;  if we can make it something
manageable by higher levels that's OK.
(Although I'm still concerned that making images with a UEFI image in
that's portable is still not going to work).

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 / dgilbert@redhat.com / Manchester, UK