[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images? |
Date: |
Thu, 7 Jun 2018 21:38:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 06/07/18 12:51, Andrea Bolognani wrote:
> On Thu, 2018-06-07 at 11:32 +0100, Richard W.M. Jones 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
>
> [...]
>> [*] I'm not sure exactly which bit of the bootloader does this,
>> whether it's UEFI itself, or the grub-efi in the guest.
>
> IIUC the UEFI spec itself reserves certain file names in the ESP
> for this fallback mechanism; it's then up to the guest operating
> system to actually install something appropriate there.
>
> In Fedora and RHEL, shim is what takes care of it (except when it
> doesn't ;), but in Debian and Ubuntu AFAIK shim is not included
> and the fallback path doesn't work at all, which makes providing
> the NVRAM file a hard requirement to boot such guests.
Quoting the UEFI-2.7 spec:
> 3.4.3 Boot Option Variables Default Boot Behavior
>
> [...] the boot options require a standard default behavior in the
> exceptional case that valid boot options are not present on a
> platform. The default behavior must be invoked any time the BootOrder
> variable does not exist or only points to nonexistent boot options, or
> if no entry in BootOrder can successfully be executed.
>
> If system firmware supports boot option recovery as described in
> Section 3.4, system firmware must include a PlatformRecovery####
> variable specifying a short-form File Path Media Device Path (see
> Section 3.1.2) containing the platform default file path for removable
> media (see Table 11). [...]
(Note from Laszlo: think '\EFI\BOOT\BOOTX64.EFI' on the system disk's
EFI System Partition.)
> It is expected that this default boot will load an operating system or
> a maintenance utility.
>
> If this is an operating system setup program it is then responsible
> for setting the requisite environment variables for subsequent boots.
> [...]
More details:
<https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>.
Thanks
Laszlo
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, (continued)
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Dr. David Alan Gilbert, 2018/06/07
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Daniel P . Berrangé, 2018/06/07
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Andrea Bolognani, 2018/06/07
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Laszlo Ersek, 2018/06/07
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Dr. David Alan Gilbert, 2018/06/08
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Daniel P . Berrangé, 2018/06/08
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Dr. David Alan Gilbert, 2018/06/08
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Michael S. Tsirkin, 2018/06/07
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Michael S. Tsirkin, 2018/06/07
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Andrea Bolognani, 2018/06/07
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?,
Laszlo Ersek <=
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Max Reitz, 2018/06/06
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Michael S. Tsirkin, 2018/06/06
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Max Reitz, 2018/06/06
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Michael S. Tsirkin, 2018/06/07
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Max Reitz, 2018/06/09
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Michael S. Tsirkin, 2018/06/10
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Michal Suchánek, 2018/06/11
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Richard W.M. Jones, 2018/06/06
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Daniel P . Berrangé, 2018/06/06
- Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?, Max Reitz, 2018/06/06