Your message dated Thu, 2 Apr 2015 12:03:00 -0700
with message-id <[email protected]>
and subject line Re: Please split into OVMF_VARS.fd and OVMF_CODE.fd
has caused the Debian Bug report #764918,
regarding Please split into OVMF_VARS.fd and OVMF_CODE.fd
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
764918: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libvirt-daemon-system
Version: 1.2.9-2
Severity: normal
Hi.
As of now qemu.conf supports NVRAM options:
# Location of master nvram file
#
# When a domain is configured to use UEFI instead of standard
# BIOS it may use a separate storage for UEFI variables. If
# that's the case libvirt creates the variable store per domain
# using this master file as image. Each UEFI firmware can,
# however, have different variables store. Therefore the nvram is
# a list of strings when a single item is in form of:
# ${PATH_TO_UEFI_FW}:${PATH_TO_UEFI_VARS}.
# Later, when libvirt creates per domain variable store, this
# list is searched for the master image.
#nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" ]
1) The locations of the respective Debian package’s file (ovmf)
seems to be different:
$ dpkg -L ovmf
/usr/share/ovmf/OVMF.fd
2) With respect to the OVMF_VARS.fd I'm a bit unsure whether I
understand it correctly.
Is this just a "template" for the UEFI variables (i.e. how
the ones for a new VM are initialised)? Or is it the storage
for the variables from the VMs?
Anyway,... in the first case it seems this file should rather
go to /etc/libvirt/, and in the second case it seems it should
go to /var/lib/libvirt/
Cheers,
Chris.
--- End Message ---
--- Begin Message ---
Hello,
I'm closing this bug as 'wontfix'. I had not wanted to implement this as
described, because "/usr/share" is clearly the wrong place to store the
nvram variable settings as these are obviously per-VM and also not
necessarily owned by root.
However, it appears that recent versions of ovmf also have support for
reading their state from a file named NvVars on the ESP of the configured
disk. This is a much better option than having a fixed location in /usr.
It also appears to work completely transparently, as my VMs have started
using this feature apparently with no action on my part, and my nvram values
now persist across VM restarts.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[email protected] [email protected]
signature.asc
Description: Digital signature
--- End Message ---
