[libvirt-users] Trouble moving OVMF guest to new host

[Bashe, Joe]

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 <abologna at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170208/4238db0c/attachment.htm>