Awesome, that worked perfectly. I just had to copy the variable store (it was in /var/lib/libvirt/qemu/nvram), and the VM booted right up!
Thank you for the help! Best regards, Joe -- Joseph Bashe Technical Director Bashe Development +1 (323) 999-1731 On Wed, Feb 8, 2017 at 4:12 PM, Andrea Bolognani <abolo...@redhat.com> wrote: > On Wed, 2017-02-08 at 20:13 +0300, Aleksei wrote: > > I'm running libvirt in user session and libvirt creates VARS part of > OVMF in ~/.config/libvirt/qemu/nvram/ > > Check your xml, there should be lines like this: > > <os> > > <type arch='x86_64' machine='pc-q35-2.7'>hvm</type> > > <loader readonly='yes' type='pflash'>/UEFI_OVMF/OVMF_ > CODE.fd</loader> > > <nvram>/home/username/.config/libvirt/qemu/nvram/vm_VARS.fd</nvram> > > ... or in /var/lib/libvirt/qemu/nvram, if you're using > the system-wide libvirtd instance. > > Anyway, Aleksei is right that you should copy over the > variable store (vm_VARS.fd) along with the disk image > and the XML configuration: some guest operating systems > are able to cope with its absence and recreate the > correct EFI variables automatically, but that's not > always the case. > > Moreover, you should make sure your /etc/libvirt/qemu.conf > file contains something along the lines of > > nvram = [ > "/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/ > usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd/OVMF_VARS-pure-efi.fd" > ] > > so that, in case the variable store for the guest is missing > or your simply creating a new guest, libvirt will be able to > create a new one by copying over the template (the "master > var store" the error was referring to). > > By the way, edk2-ovmf is included in Fedora proper these > days, you don't need to use edk2.git-ovmf-x64 any longer ;) > > -- > Andrea Bolognani / Red Hat / Virtualization >
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users