[SRU] BDM with device_type=lun fails

[Dan Smith]

Original Bug Description Below

[ Impact ]

* On OpenStack Caracal, it is not possible to create a libvirt-backed LUN because OpenStack tries to create the volumes with a "serial" property that libvirt does not support. See [1] in libvirt source code, which demonstrates that for a long time (since at least 2015) the serial property has been incompatible with LUN devices

* Libvirt rejects the creation of the volume with the error: "unsupported configuration: scsi-block 'lun' devices do not support the serial property"

* The OpenStack volumes do not need the "serial" property, since they can be managed entirely by their alias

* The above issues are resolved by the commit at [2]

* From qemu's perspective, LUNs are hds. Therefore, in order for the boot order to be calculated properly, the libvirt driver needs to be aware that the lun device type maps to a qemu hd. This is addressed in [3]

[1] https://github.com/libvirt/libvirt/commit/4fce9e84798be1441d8bc5b96f0ed68589e85222
[2] https://review.opendev.org/c/openstack/nova/+/918089/3
[3] https://review.opendev.org/c/openstack/nova/+/918470/2

[ Test Plan ]

* Deploy an OpenStack cloud with cinder-lvm support

* Create a volume type for the LUNs

openstack volume type create lun-volumes

* Enforce that LUNs use the default LVM backing

openstack volume type set --property volume_backend_name="LVM-default" lun-volumes

* Create a LUN volume

openstack volume create --size 5 --type lun-volumes volume1

export LUN_UUID=<UUID of volume1>

* Create another volume

openstack volume create --size 5 volume2

export SECOND_VOL_UUID=<UUID of volume2>

* Create a server with volume1 and volume2 attached, specifying volume1 as a scsi lun device

openstack server create \
  --block-device source_type=volume,destination_type=volume,disk_bus=scsi,device_type=lun,uuid=${LUN_UUID} \
  --block-device source_type=volume,destination_type=volume,uuid=${SECOND_VOL_UUID} \
  --flavor m1.small \
  --network private \
  --image focal server1 \
  --key-name testkey \
  --os-compute-api-version 2.60

* ssh into the vm and use lsblk to confirm that there's a root/ephemeral disk plus the two attached (LUN will be /sda, ephemeral will be /vda, and volume2 will be /vdb)

Without the patches the above will fail to create (server enters ERROR state and is unusable) with the following error. Whereas with the patches, the server will successfully boot and enter RUNNING state, validating the device's successful creation and that correct boot order determination

libvirt.libvirtError: unsupported configuration: scsi-block 'lun' devices do not support the serial property

2025-12-08 11:39:54.493 1724625 ERROR nova.virt.libvirt.driver [None req-f6867ac6-58f4-402c-ac88-287606365aae ebdea9035cf242b9b8b8ca1471743525 82c2f393a54342bd84e35d7e0a1afa13 - - 38a77ae8848b4cd1921b7f54e70c4c9d 38a77ae8848b4cd1921b7f54e70c4c9d] [instance: e1ee5cb0-eda6-40cc-9386-62621e0b73ec] Failed to start libvirt guest: libvirt.libvirtError: unsupported configuration: scsi-block 'lun' devices do not support the serial property

[ Where problems could occur ]

* This is removing a property that's commonly used to identify volumes, which could be problematic. However, it is only removed for LUN devices, and it is only removed from the libvirt XML, which never supported this property for LUN devices anyways, so the risks are low.

* OpenStack volumes are intended to be managed entirely by aliases, however, if any feature such as volume migrations or volume retyping relies on the serial property it may not work for LUNs. This has a low risk of affecting existing environments since this bug prevents users from creating libvirt-backed LUNs

* Users will need to be mindful that LUNs are qemu hds when considering their boot order. This is also low-risk for regression because existing environments are not able to create LUNs

[ Other Info ]

* The patches merged upstream during the Dalmation (24.10) cycle. Therefore, this SRU is targetting Noble for the distro, and Jammy-Caracal for the Ubuntu Cloud Archive

* PPA with packages built from this debdiff: https://launchpad.net/~bryanfraschetti/+archive/ubuntu/lp2065084-nova-luns

* Upstream backports to unmaintained/2024.1:
  - https://review.opendev.org/c/openstack/nova/+/974232/1
  - https://review.opendev.org/c/openstack/nova/+/974233/1

Original description:
=====================

Libvirt recently (since our code was added) refuses the serial option on a disk which is attached as a LUN. Since we officially support this in our API, we need to avoid putting serial on those disks.

Also, even when we don't hit that problem, our boot order calculation fails with:

56694407 tempest-AttachVolumeMultiAttachTest-1756694407-project-member] [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] Failed to build and run instance: KeyError: 'lun'
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] Traceback (most recent call last):
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] File "/opt/stack/nova/nova/compute/manager.py", line 2641, in _build_and_run_instance
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] self.driver.spawn(context, instance, image_meta,
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4642, in spawn
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] xml = self._get_guest_xml(context, instance, network_info,
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7814, in _get_guest_xml
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] conf = self._get_guest_config(instance, network_info, image_meta,
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7318, in _get_guest_config
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] self._conf_non_lxc(
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 6969, in _conf_non_lxc
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] guest.os_boot_dev = blockinfo.get_boot_order(disk_info)
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] File "/opt/stack/nova/nova/virt/libvirt/blockinfo.py", line 737, in get_boot_order
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] return uniq(boot_devs_dup)
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] File "/opt/stack/nova/nova/virt/libvirt/blockinfo.py", line 735, in uniq
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] return [el for el in lst if el not in s and not s.add(el)]
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] File "/opt/stack/nova/nova/virt/libvirt/blockinfo.py", line 735, in <listcomp>
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] return [el for el in lst if el not in s and not s.add(el)]
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] File "/opt/stack/nova/nova/virt/libvirt/blockinfo.py", line 729, in <genexpr>
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] boot_devs_dup = (BOOT_DEV_FOR_TYPE[dev['type']] for dev in
May 07 17:16:33 jammy nova-compute[133963]: ERROR nova.compute.manager [instance: 4a20e558-dba6-4daa-af66-b62de2d9c0f3] KeyError: 'lun'

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/nova/+/918089
Committed: https://opendev.org/openstack/nova/commit/575ff86a4f1572786d66639f774405fbc074fdb1
Submitter: "Zuul (22348)"
Branch: master

commit 575ff86a4f1572786d66639f774405fbc074fdb1
Author: Dan Smith <email address hidden>
Date: Fri May 3 08:55:50 2024 -0700

    Avoid setting serial on raw LUN devices

    Libvirt now enforces that device="lun" (i.e. raw device passthrough)
    disks must not have the <serial> property set. We recently enabled
    the ability to manage devices by alias instead of serial, but to
    fully enable this use-case we need to avoid putting serial in the
    XML to appease libvirt.

    Related-Bug: #2065084
    Change-Id: Ifa2df89f27e58e1e64ce046edeaf6e49a7c89490

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/nova/+/918470
Committed: https://opendev.org/openstack/nova/commit/2f0c340d3910f48ab4609f477b76aa69da2f2bbb
Submitter: "Zuul (22348)"
Branch: master

commit 2f0c340d3910f48ab4609f477b76aa69da2f2bbb
Author: Dan Smith <email address hidden>
Date: Tue May 7 10:31:11 2024 -0700

    Fix device_type=lun with boot_index

    Right now we'll fail to calculate the boot order of a set of BDMs if
    one of them is a device_type=lun. This fixes that and teaches us
    that it's just a "hd" from qemu's perspective.

    Closes-Bug: #2065084
    Change-Id: Ic1340918738d503fc797c9373fe2e1dd16b27a09

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 30.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/2024.1
Review: https://review.opendev.org/c/openstack/nova/+/945594

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/2024.1
Review: https://review.opendev.org/c/openstack/nova/+/945595

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Elod Illes <email address hidden>" on branch: stable/2024.1
Review: https://review.opendev.org/c/openstack/nova/+/945594
Reason: stable/2024.1 branch of openstack/nova is about to be deleted. To be able to do that, all open patches need to be abandoned. Please cherry pick the patch to unmaintained/2024.1 if you want to further work on this patch.

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Elod Illes <email address hidden>" on branch: stable/2024.1
Review: https://review.opendev.org/c/openstack/nova/+/945595
Reason: stable/2024.1 branch of openstack/nova is about to be deleted. To be able to do that, all open patches need to be abandoned. Please cherry pick the patch to unmaintained/2024.1 if you want to further work on this patch.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: unmaintained/2024.1
Review: https://review.opendev.org/c/openstack/nova/+/974232

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: unmaintained/2024.1
Review: https://review.opendev.org/c/openstack/nova/+/974233

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "noble-lp2065084.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Matthew Ruffell (mruffell)]

Sponsored for noble, thanks.

Uploading nova_29.2.0-0ubuntu1.3.dsc
Uploading nova_29.2.0-0ubuntu1.3.debian.tar.xz
Uploading nova_29.2.0-0ubuntu1.3_source.buildinfo
Uploading nova_29.2.0-0ubuntu1.3_source.changes