<div dir="ltr">I always appreciate when someone with the knowledge takes the time to explain why a specific solution works - thank you, Laszlo.</div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Apr 15, 2016 at 6:08 AM, Laszlo Ersek <<a href="mailto:lersek@redhat.com" target="_blank">lersek@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/15/16 10:45, Philip Abernethy wrote: > I'm using extra/ovmf on my machine and just had to add > > nvram = [ > "/usr/share/ovmf/ovmf_x64.bin:/usr/share/ovmf/ovmf_x64.bin" > ] Ouch. That hurt. A lot. - Elements in the nvram list are pairs. - Each pair has a first component, and a second component. - The first component is a firmware binary. - The second component is a variable store template that is compatible with the firmware binary in the first component. - When you create a new virtual machine with libvirt, you specify the firmware binary that you want to use. This is a selection from the first column. - Libvirt will map your selection to the second component (the varstore template that is compatible with the firmware binary that you selected). - For the new VM, it will create a copy of that varstore template. - This copy is called the VM's own private variable store. Generally, it lives under /var/lib/libvirt/qemu/nvram/. - The VM will use the firmware binary (= first component) directly. - The VM will never use the varstore template (= second component). It will use its own private varstore, which came into existence as a copy of the varstore template (= second component). - When you upgrade your OVMF package, the VM will pick up the upgraded firmware binary the next time it is shut down and relaunched. The VM's private varstore will not be affected by the package upgrade in any way. That's the *entire point* of the split files scheme. For example, on my laptop, I have nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd", "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd", "/home/virt-images/OVMF_CODE.32.fd:/home/virt-images/OVMF_VARS.fd", "/home/virt-images/OVMF_CODE.3264.fd:/home/virt-images/OVMF_VARS.fd", "/home/virt-images/OVMF_CODE.fd:/home/virt-images/OVMF_VARS.fd", "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd", "/usr/share/AAVMF/AAVMF_CODE.verbose.fd:/usr/share/AAVMF/AAVMF_VARS.fd" ] * If I pick the /home/virt-images/OVMF_CODE.3264.fd firmware binary (which is the first component of the 4th element), then libvirt will map it to the /home/virt-images/OVMF_VARS.fd variable store template (which is the second component of the 4th element). Then the new VM's own varstore will be created as a copy of /home/virt-images/OVMF_VARS.fd * If I pick /usr/share/AAVMF/AAVMF_CODE.verbose.fd (1st component of the 7th element) then libvirt will map it to the /usr/share/AAVMF/AAVMF_VARS.fd varstore template (2nd component of the 7th element). The new VM's own varstore will be then created as a copy of this latter file. * Assuming that on an ArchLinux host, you have the following two files: /usr/share/ovmf/x64/ovmf_code_x64.bin -- firmware binary /usr/share/ovmf/x64/ovmf_vars_x64.bin -- varstore template that is compatible with the above Your nvram list should look like: nvram = [ "/usr/share/ovmf/x64/ovmf_code_x64.bin:/usr/share/ovmf/x64/ovmf_vars_x64.bin" ] * If you use Gerd's "edk2.git-ovmf-x64" package, then: nvram = [ "/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd" "/usr/share/edk2.git/ovmf-x64/OVMF_CODE-need-smm.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-need-smm.fd" "/usr/share/edk2.git/ovmf-x64/OVMF_CODE-with-csm.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-with-csm.fd" ] and when you create a new VM, you should pick the first one: /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd unless you have specific reasons for picking the second or the third. Laszlo </blockquote></div> </div>