Results 1 to 7 of 7

Thread: QEMU/KVM non persistent nvram on uefi virtual machine

  1. #1

    Default QEMU/KVM non persistent nvram on uefi virtual machine

    Hi,
    I need to use uefi bios in my virtual machine (libvirt - qemu/kvm all installed through yast) so i installed ovmf packages. I noticed that bios settings (nvram data) do not persist across reboot of the virtual machine.

    From what I have read this portion of the VM configuration file should grant nvram persistence:
    Code:
      <os>
        <type arch='x86_64' machine='pc-i440fx-2.9'>hvm</type>
        <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x86_64-ms-code.bin</loader>
        <nvram>/var/lib/libvirt/qemu/nvram/opensuse42.3_VARS.fd</nvram>
        <bootmenu enable='yes'/>
      </os>
    Any ideas?

    Thank you all

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    15,684
    Blog Entries
    3

    Default Re: QEMU/KVM non persistent nvram on uefi virtual machine

    It's working here. However, I can only have one NVRAM system name defined. If I try to define the second, I lose the first. (My Dell desktop does the same thing). The NVRAM is being saved in "/var/lib/libvirt/qemu/nvram". Have you checked that directory to see if there is an appropriate file name?

    Maybe you could give a bit more information on what you are trying to do and is failing.
    openSUSE Leap 15.3; KDE Plasma 5.18.6;

  3. #3

    Default Re: QEMU/KVM non persistent nvram on uefi virtual machine

    Quote Originally Posted by nrickert View Post
    It's working here. However, I can only have one NVRAM system name defined. If I try to define the second, I lose the first. (My Dell desktop does the same thing). The NVRAM is being saved in "/var/lib/libvirt/qemu/nvram". Have you checked that directory to see if there is an appropriate file name?

    Maybe you could give a bit more information on what you are trying to do and is failing.
    Hi,
    yes the nvram file is is in /var/lib/libvirt/qemu/nvram, accessible rw only for the qemu user. My requirement is very simple, i would like to save boot entry so they can persist across reboot/shutdown. I tried to set boot options both via efibootmgr from within the virtualized OS and via the efi bios interface at vm startup. In both case my settings are lost after shutdown or reboot.
    So in your system are you able to save boot options?

    Thank you very much!

  4. #4
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    15,684
    Blog Entries
    3

    Default Re: QEMU/KVM non persistent nvram on uefi virtual machine

    Quote Originally Posted by jjletho View Post
    So in your system are you able to save boot options?
    I have occasionally been doing:
    Code:
    efibootmgr -n 9
    And on the next boot, it boots to the efi shell (nvram entry 0009).

    I also tried:
    Code:
    efibootmgr -o 0,1
    but that one did not stick. Apparently the ovmf firmware will accept 0 or 9 for the next boot, but won't accept them as part of the normal boot order.

    I have a VM, where I have both ubuntu 17.10, and Solus 4.18 installed. I first installed ubuntu, and left a partition for solus. Then, booting to the efi shell, I was able to get it to boot the Solus installer to add that.

    Unfortunately, Solus does a poor job of installing. It failed to add an NVRAM boot entry for Solus. So I manually added one from ubuntu. And that worked just fine for booting Solus. Unfortunately, the ovmf firmware then deleted the NVRAM entry for ubuntu. So I added that back from Solus, and the firmware deleted the Solus entry. It seems to only like one entry in addition to its fallback entries (0 and 9). I added a grub entry to the ubuntu system, that chainloads the Solus efi boot loader. That was I can boot either from the ubuntu menu.

    This was all experimenting. And I should mention that I installed that one using "ovmf-x86_64-code.bin" (installed with "virt-install"), because Solus does not support secure-boot.

    I mention the examples just to illustrate what is working.
    openSUSE Leap 15.3; KDE Plasma 5.18.6;

  5. #5

    Default Re: QEMU/KVM non persistent nvram on uefi virtual machine

    Quote Originally Posted by nrickert View Post
    I have occasionally been doing:
    Code:
    efibootmgr -n 9
    And on the next boot, it boots to the efi shell (nvram entry 0009).

    I also tried:
    Code:
    efibootmgr -o 0,1
    but that one did not stick. Apparently the ovmf firmware will accept 0 or 9 for the next boot, but won't accept them as part of the normal boot order.

    I have a VM, where I have both ubuntu 17.10, and Solus 4.18 installed. I first installed ubuntu, and left a partition for solus. Then, booting to the efi shell, I was able to get it to boot the Solus installer to add that.

    Unfortunately, Solus does a poor job of installing. It failed to add an NVRAM boot entry for Solus. So I manually added one from ubuntu. And that worked just fine for booting Solus. Unfortunately, the ovmf firmware then deleted the NVRAM entry for ubuntu. So I added that back from Solus, and the firmware deleted the Solus entry. It seems to only like one entry in addition to its fallback entries (0 and 9). I added a grub entry to the ubuntu system, that chainloads the Solus efi boot loader. That was I can boot either from the ubuntu menu.

    This was all experimenting. And I should mention that I installed that one using "ovmf-x86_64-code.bin" (installed with "virt-install"), because Solus does not support secure-boot.

    I mention the examples just to illustrate what is working.
    Hi
    thank you for your hints. I did some further tests discovering this: boot entries configured through efibootmgr do not persist. Boot entries added through the uefi bios textual user interface persist only if I change the boot order and save them hitting F10.
    I suppose ovmf code has some bugs.

  6. #6
    Join Date
    Sep 2012
    Posts
    7,106

    Default Re: QEMU/KVM non persistent nvram on uefi virtual machine

    Quote Originally Posted by jjletho View Post
    Hi
    boot entries configured through efibootmgr do not persist
    The following works for me:
    Code:
    qemu-system-x86_64 -machine q35 -cpu kvm64 -enable-kvm -m 1G -device virtio-scsi-pci -pflash vm/ovmf/ovmf-x86_64-code.bin -pflash vm/ovmf/ovmf-x86_64-vars.bin -net user -net nic -drive file=Загрузки/openSUSE-Leap-42.3-DVD-x86_64.iso/openSUSE-Leap-42.3-DVD-x86_64.iso,format=raw,id=cd0,if=none -device scsi-cd,drive=cd0 &
    Boot entry added with efibootmgr persits after stopping and restarting VM. OVMF is from OBS Virtualization:ovmf.

  7. #7
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    15,684
    Blog Entries
    3

    Default Re: QEMU/KVM non persistent nvram on uefi virtual machine

    Quote Originally Posted by jjletho View Post
    I did some further tests discovering this: boot entries configured through efibootmgr do not persist. Boot entries added through the uefi bios textual user interface persist only if I change the boot order and save them hitting F10.
    I'm not sure what you are doing differently.

    I just tested. I used "efibootmgr -n 9". Then I shutdown the virtual machine. On reboot, it started with the efi shell.

    I actually tested this twice. First test was with a VM using "ovmf-x86_64-ms.bin". The second was with a VM using "ovmf-x86_64.bin".

    I installed "ovmf" using Yast (from the standard Leap 42.3 repos).

    To create a virtual machine with "ovmf-x86_64-ms.bin", I use Yast/Virtualization/Create Virtual Machines
    During setup, on 4th (or is it 5th) screen I check the box to modify configuration before starting. And then I switch from BIOS to the UEFI boot code.

    To create a virtual machine with "ovmf-x86_64.bin" (i.e. without secure-boot), I use the "virt-install" command (as root), with a long command line. To run a virtual machine, I start virt-manager.
    openSUSE Leap 15.3; KDE Plasma 5.18.6;

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •