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

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

* Andrea Bolognani (abologna@redhat.com) wrote:
> On Thu, 2018-06-07 at 15:45 +0100, Dr. David Alan Gilbert wrote:
> > * Andrea Bolognani (abologna@redhat.com) wrote:
> > > On Thu, 2018-06-07 at 14:49 +0100, Dr. David Alan Gilbert wrote:
> > > > Including the nvram and efi makes me nervous; but I can see why together
> > > > they might work.  However, there's no guarantee that EFI has been tested
> > > > with the QEMU it's used on and ... that could be trouble.
> > > 
> > > If the QEMU binary doesn't support EFI, then a guest expecting
> > > EFI won't be able to start regardless of where the EFI ROM came
> > > from.
> > 
> > No, I mean if the QEMU doesn't support that *particular* EFI.
> 
> I could be wrong, but I feel like it's significantly less likely
> that a random QEMU binary won't like a random EFI ROM than it is
> for a random EFI ROM to not like a random EFI NVRAM.

True, but it's not that rare to find SeaBIOS+qemu version problems;
so I'll assume the same happens with EFI.

> > > > Also, if we're going to start including the EFI rom then that would have
> > > > to be migrated with the VM so that after a restart on a different host
> > > > it's still using the right ROM that's compatible with it's varfile.
> > > 
> > > That's a problem that needs to be addressed anyway, because even
> > > as it is now you could easily find yourself trying and failing
> > > to migrate a guest between two hosts that have different and
> > > incompatible EFI ROMs installed.
> > 
> > True; although I was working on the basis that vendors who cared about
> > migration compatibility would couple the EFI versions with machine types
> > to ensure that the variable data didn't become incompatible.
> 
> As far as I know, nobody is actually doing this at the moment.

I'm assuming we'll have to.

Dave


> -- 
> Andrea Bolognani / Red Hat / Virtualization
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK