[Bug 2122288] Re: Lack of proper handling of new firmware architectures

Mon Feb 16 12:27:17 UTC 2026

** Also affects: cloud-archive/flamingo
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/epoxy
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/dalmatian
   Importance: Undecided
       Status: New

** Also affects: nova (Ubuntu Questing)
   Importance: Undecided
       Status: New

** Also affects: nova (Ubuntu Resolute)
   Importance: Undecided
       Status: New

** Also affects: nova (Ubuntu Noble)
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/gazpacho
   Importance: Undecided
       Status: New

-- 
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 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:
  New
Status in OpenStack Compute (nova):
  Fix Released
Status in nova package in Ubuntu:
  New
Status in nova source package in Noble:
  New
Status in nova source package in Questing:
  New
Status in nova source package in Resolute:
  New

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