[Bug 2122288] Re: Lack of proper handling of new firmware architectures
Marcin Wilk
2122288 at bugs.launchpad.net
Tue Mar 17 11:09:05 UTC 2026
It looks to me that we don't need to backport it to EOL UCA releases
(Dalmatian and Epoxy) because this patch is not critical for the upgrade
process. Without the patch, users will not be able to create UEFI-
enabled VMs.
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/2122288
Title:
Lack of proper handling of new firmware architectures
Status in Ubuntu Cloud Archive:
New
Status in Ubuntu Cloud Archive caracal series:
New
Status in Ubuntu Cloud Archive dalmatian series:
New
Status in Ubuntu Cloud Archive epoxy series:
New
Status in Ubuntu Cloud Archive flamingo series:
New
Status in Ubuntu Cloud Archive gazpacho series:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Status in nova package in Ubuntu:
In Progress
Status in nova source package in Noble:
In Progress
Status in nova source package in Questing:
In Progress
Status in nova source package in Resolute:
In Progress
Bug description:
[ Impact ]
Users reported that when trying to launch a VM from the UEFI-enabled image on Ubuntu 24.04 (Noble) with ovmf package versions 2024.02-2ubuntu0.5 and later, the VM fails to launch because nova doesn't know some of the libvirt-provided firmware features. As a result, they can't run UEFI-booted VMs.
This problem has already been resolved in the upstream code [1]. I
have verified that the upstream patch fixes the problem with launching
a UEFI-enabled VM on Resolute and Questing.
[1]
https://opendev.org/openstack/nova/commit/d2188b9e6b35ba512661711165cef706f8bed693
[ Test Plan ]
1. Deploy the regress-stack on a Resolute VM
(make sure the VM has enough resources to run regress-stack):
sudo apt update && sudo apt upgrade -y
sudo apt install -y dpkg-dev python3-dev python-apt-dev
sudo snap install astral-uv --classic
git clone https://github.com/canonical/regress-stack.git
cd regress-stack
# Python and dependency version pinning
uv python pin 3.13
sed -i 's/requires-python = ".*"/requires-python = ">=3.13"/' pyproject.toml
sed -i 's/^ "python-apt"/# "python-apt"/' pyproject.toml
sed -i 's/^python-apt =/#python-apt = /' pyproject.toml
# Nova and Neutron service name fixes
sed -i 's/ core_utils.restart_service("neutron-server")/ core_utils.restart_service("apache2")/' src/regress_stack/modules/neutron.py
sed -i '/ core_utils.restart_service("neutron-ovn-metadata-agent")/a\ core_utils.restart_service("neutron-periodic-workers")' src/regress_stack/modules/neutron.py
sed -i '/ core_utils.restart_service("neutron-ovn-metadata-agent")/a\ core_utils.restart_service("neutron-rpc-server")' src/regress_stack/modules/neutron.py
sed -i 's/ core_utils.restart_service("nova-api")/ core_utils.restart_service("apache2")/' src/regress_stack/modules/nova.py
uvx pre-commit install
uv venv --system-site-packages --python-preference system
uv sync
uv run py.test
sudo apt install -y crudini ceph-mgr ceph-mon ceph-osd ceph-volume mysql-server keystone apache2 libapache2-mod-wsgi-py3 glance-api ovn-central openvswitch-switch ovn-host placement-api rabbitmq-server cinder-api cinder-scheduler cinder-volume neutron-server neutron-ovn-metadata-agent nova-api nova-conductor nova-scheduler nova-compute nova-spiceproxy spice-html5
sudo uv run regress-stack setup
sudo cp /root/auth.rc ~
sudo chown $(id -u):$(id -g) ~/auth.rc
source ~/auth.rc
# verify OpenStack is up and running:
openstack endpoint list
openstack service list
openstack hypervisor list
2. Create required resources in OpenStack
wget https://cloud-images.ubuntu.com/releases/noble/release/ubuntu-24.04-server-cloudimg-amd64.img
openstack flavor create --ram 2048 --vcpus 1 --disk 20 m1.small
openstack keypair create testkey
openstack network create private
openstack subnet create --network private --ip-version 4 --subnet-range 192.168.21.0/24 --allocation-pool start=192.168.21.2,end=192.168.21.254 private_subnet
openstack image create --container-format bare --disk-format qcow2 --public --file ubuntu-24.04-server-cloudimg-amd64.img noble_uefi
openstack image set --property hw_machine_type=q35 --property hw_firmware_type=uefi noble_uefi
3. Try to create a UEFI-enabled VM:
openstack server create --image noble_uefi --flavor m1.small --key-name testkey --network private noble1
Without the patch, the VM will end up in the ERROR state, /var/log/nova/nova-compute.log will contain the following error messages:
2026-02-12 16:11:34.693 47928 INFO nova.virt.libvirt.host [None req-e741f97a-3201-40fc-9bb5-a76e2d378697 85da01e2dffd4b7d83a4ce1fb1713a39 b71f3390a85142b2aa247e9070bd469b - - default default] UEFI support detected
2026-02-12 16:11:34.694 47928 ERROR nova.compute.manager [None req-e741f97a-3201-40fc-9bb5-a76e2d378697 85da01e2dffd4b7d83a4ce1fb1713a39 b71f3390a85142b2aa247e9070bd469b - - default default] [instance: c5c12f18-4189-4eeb-8784-97e6f77ea8fb] Instance failed to spawn: KeyError: 'nvram-template'
With the patch applied, the VM will be successfully created
[ Where problems could occur ]
The patch modifies the code related/isolated to the UEFI-enabled VMs on KVM/libvirt hypervisors. The code change is small. If it causes a regression, most likely, a UEFI-enabled VM would not launch (but they don't launch already due to this bug). The /var/log/nova/nova-compute.log log should be examined to get a better understanding wof hat went wrong.
[ Other Info ]
The original bug description:
Description
===========
Recent CentOS and Fedora introduced a few new architecture patterns of OVMF firmware.
However current nova does not handle these patterns appropriately and assumes that every firmware is always "statefull" and also "plash" type.
1) mode=stateless
example. 60-edk2-ovmf-x64-amdsev.json in Fedora 40
---
{
"description": "OVMF with SEV-ES support",
"interface-types": [
"uefi"
],
"mapping": {
"device": "flash",
"mode": "stateless",
"executable": {
"filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd",
"format": "raw"
}
},
"targets": [
{
"architecture": "x86_64",
"machines": [
"pc-q35-*"
]
}
],
"features": [
"amd-sev",
"amd-sev-es",
"amd-sev-snp",
"verbose-dynamic"
],
"tags": [
]
}
---
2) device=memory
example. 60-edk2-ovmf-x64-amdsev.json in CentOS Stream 10
---
{
"description": "OVMF with SEV-ES support",
"interface-types": [
"uefi"
],
"mapping": {
"device": "memory",
"filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd"
},
"targets": [
{
"architecture": "x86_64",
"machines": [
"pc-q35-*"
]
}
],
"features": [
"amd-sev",
"amd-sev-es",
"amd-sev-snp",
"verbose-dynamic"
],
"tags": [
]
}
---
These files should be excluded when detecting the loader files, to
avoid KeyError or launch time error.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2122288/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list