From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQwnY-0005Sb-Hc for qemu-devel@nongnu.org; Thu, 07 Jun 2018 11:26:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQwnX-0002Nj-Jg for qemu-devel@nongnu.org; Thu, 07 Jun 2018 11:26:00 -0400 Date: Thu, 7 Jun 2018 16:25:48 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20180607152548.GQ2522@work-vm> References: <66727986-1cf1-c12e-d78c-d56cc15eaf00@redhat.com> <20180606163246.GL3064@redhat.com> <20180607102257.GH28827@redhat.com> <2afb9305deb37c8ca4f930235eaf52486ab0153e.camel@redhat.com> <20180607123847.GL28827@redhat.com> <20180607134953.GN2522@work-vm> <63fece55c4708744d9289fedf42d67ebb1bccbdd.camel@redhat.com> <20180607144527.GO2522@work-vm> <6d393743ee2358c900448a949734fc565a148050.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6d393743ee2358c900448a949734fc565a148050.camel@redhat.com> Subject: Re: [Qemu-devel] storing machine data in qcow images? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Bolognani Cc: Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Eric Blake , Kevin Wolf , qemu-block@nongnu.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, armbru@redhat.com, "Richard W.M. Jones" , stefanha@redhat.com, Max Reitz * 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