Going along the chain of events I believe with the switch to a non-UEFI image during REBUILD the information that there WAS an NVRAM present due to the previously used UEFI-enabled image is lost, thus the delete_configuration does to work anymore causing the rebuild to fail.
My take would be:
Why not always delete the NVRAM if the hosts has UEFI support, just in case? Is that call really that expensive? By calling "delete_configuration" I simply want to end up with a deleted configuration / domain.
This was tested using OpenStack Xena.
There were no changes to the `delete_ configuration` method itself https:/ /opendev. org/openstack/ nova/blame/ commit/ f9dc9f259bfff5a c9424b4acb8575b f8c2463113/ nova/virt/ libvirt/ guest.py# L298, but there was https:/ /bugs.launchpad .net/nova/ +bug/1845628 and the resulting https:/ /review. opendev. org/c/openstack /nova/+ /685678.
Going along the chain of events I believe with the switch to a non-UEFI image during REBUILD the information that there WAS an NVRAM present due to the previously used UEFI-enabled image is lost, thus the delete_ configuration does to work anymore causing the rebuild to fail.
My take would be:
Why not always delete the NVRAM if the hosts has UEFI support, just in case? Is that call really that expensive? By calling "delete_ configuration" I simply want to end up with a deleted configuration / domain.