Description of problem: Can't remove nvram file with --nvram option when undefine an ovmf guest with firmware='efi' Version-Release number of selected component (if applicable): libvirt-5.6.0-4.module+el8.1.0+4160+b50057dc.x86_64 kernel-4.18.0-135.el8.x86_64 qemu-kvm-4.1.0-6.module+el8.1.0+4164+854d66f5.x86_64 How reproducible: 100% Steps to Reproduce: SC1: Shouldn't undefine ovmf guest without nvram option 1. Define and start a guest with firmware='efi' # virsh dumpxml ovmf --inactive | grep '/os' -B3 <os firmware='efi'> <type arch='x86_64' machine='pc-q35-rhel8.1.0'>hvm</type> <boot dev='hd'/> </os> # virsh dumpxml ovmf | grep '/os' -B5 <os> <type arch='x86_64' machine='pc-q35-rhel8.1.0'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader> <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd'>/var/lib/libvirt/qemu/nvram/ovmf_VARS.fd</nvram> <boot dev='hd'/> </os> # virsh list --all Id Name State --------------------------------- 2 ovmf running 2. Destroy the guest and undefine it without options. # virsh destroy ovmf Domain ovmf destroyed # virsh undefine ovmf Domain ovmf has been undefined # virsh list --all Id Name State --------------------------------- SC2: Can't remove nvram file with --nvram option 1. Repeat step1 in SC1 2. Destroy the guest and undefine it with --nvram option. # virsh destroy ovmf Domain ovmf destroyed # virsh undefine ovmf --nvram Domain ovmf has been undefined # ll /var/lib/libvirt/qemu/nvram/ total 528 -rw-------. 1 root root 540672 Sep 12 04:00 ovmf_VARS.fd # virsh list --all Id Name State --------------------------------- Actual results: SC1: can undefine ovmf guest without options SC2: can't remove ovmf file when undefine guest with nvram option Expected results: SC1: should have an error message when undefine ovmf guest without options # virsh undefine ovmf error: Failed to undefine domain ovmf error: Requested operation is not valid: cannot undefine domain with nvram SC2: The ovmf_VARS.fd file should be removed. Additional info:
Looks like regression since it was already fixed in bug 1467245.
Oh, the problem is that if domain is not running then os.firmare='efi' does not populate domain definition with domain specific NVRAM file and thus qemuDomainUndefineFlags() doesn't see the file and thus allows undefine even though the file exists. The fix would consist of moving virAsprintf() from qemuDomainNVRAMPathGenerate() into a function so that the domain specific NVRAM path can be generated in case of os.firmware='efi'. I'm moving this bug to Pavel as this is a great opportunity to learn something new and fix a simple bug whilst doing so.
I've just pushed the patch upstream: b5308a1205 qemu: fix EFI nvram removal on domain undefine v5.8.0-171-gb5308a1205
Verified in : libvirt-5.6.0-9.module+el8.1.1+4955+f0b25565.x86_64 kernel-4.18.0-147.0.3.el8_1.x86_64 qemu-kvm-4.1.0-17.module+el8.1.1+5019+2d64ad78.x86_64 Sc1:Undefine the guest without option "--nvram" # virsh list --all Id Name State --------------------------------- 1 demo running # virsh dumpxml demo |grep "os" -A5 <os> <type arch='x86_64' machine='pc-q35-rhel8.1.0'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader> <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd'>/var/lib/libvirt/qemu/nvram/ovmf_VARS.fd</nvram> <boot dev='hd'/> </os> # virsh destroy ovmf Domain ovmf destroyed # virsh undefine demo error：Requested operation is not valid: cannot undefine domain with nvram Sc2:Undefine the guest with option "--nvram" # ll /var/lib/libvirt/qemu/nvram/ total 528 -rw-------. 1 root root 540672 Dec 4 01:50 ovmf_VARS.fd # virsh undefine demo --nvram Domain demo has been undefined # ll /var/lib/libvirt/qemu/nvram/ total 0 Sc3:Undefine the guest with option "--keep-nvram" # ll /var/lib/libvirt/qemu/nvram/ total 528 -rw-------. 1 root root 540672 Dec 4 01:50 ovmf_VARS.fd # virsh undefine demo --keep-nvram Domain demo has been undefined # ll /var/lib/libvirt/qemu/nvram/ total 528 -rw-------. 1 root root 540672 Dec 4 01:50 ovmf_VARS.fd Work as expected
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0404