qemu: Don't overwrite NVRAM template for legacy firmware

Just because we have found a matching entry, it doesn't mean
that we should discard the information explicitly provided in
the domain XML.

https://bugzilla.redhat.com/show_bug.cgi?id=2196178
https://gitlab.com/libvirt/libvirt/-/issues/500

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This commit is contained in:
Andrea Bolognani 2023-05-26 19:59:06 +02:00
parent 1b3e9c67e3
commit 4a49114ff4
2 changed files with 25 additions and 3 deletions

View File

@ -1609,7 +1609,29 @@ qemuFirmwareFillDomainLegacy(virQEMUDriver *driver,
loader->type = VIR_DOMAIN_LOADER_TYPE_PFLASH;
loader->readonly = VIR_TRISTATE_BOOL_YES;
VIR_FREE(loader->nvramTemplate);
/* Only use the default template path if one hasn't been
* provided by the user.
*
* In addition to fully-custom templates, which are a valid
* use case, we could simply be in a situation where
* qemu.conf contains
*
* nvram = [
* "/path/to/OVMF_CODE.secboot.fd:/path/to/OVMF_VARS.fd",
* "/path/to/OVMF_CODE.secboot.fd:/path/to/OVMF_VARS.secboot.fd"
* ]
*
* and the domain has been configured as
*
* <os>
* <loader readonly='yes' type='pflash'>/path/to/OVMF_CODE.secboot.fd</loader>
* <nvram template='/path/to/OVMF/OVMF_VARS.secboot.fd'>
* </os>
*
* In this case, the global default is to have Secure Boot
* disabled, but the domain configuration explicitly enables
* it, and we shouldn't overrule this choice */
if (!loader->nvramTemplate)
loader->nvramTemplate = g_strdup(cfg->firmwares[i]->nvram);
qemuFirmwareEnsureNVRAM(def, cfg, VIR_STORAGE_FILE_RAW);

View File

@ -7,7 +7,7 @@
<os>
<type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
<loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
<nvram template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram>
<nvram template='/usr/share/OVMF/OVMF_VARS.secboot.fd'>/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram>
<boot dev='hd'/>
</os>
<features>