[Bug 2065084] Re: BDM with device_type=lun fails
Bryan Fraschetti
2065084 at bugs.launchpad.net
Wed Jan 21 14:07:39 UTC 2026
** Also affects: cloud-archive
Importance: Undecided
Status: New
** Also affects: cloud-archive/caracal
Importance: Undecided
Status: New
** Also affects: cloud-archive/dalmatian
Importance: Undecided
Status: New
** Changed in: cloud-archive/dalmatian
Status: New => Fix Released
** Also affects: nova (Ubuntu)
Importance: Undecided
Status: New
** Also affects: nova (Ubuntu Noble)
Importance: Undecided
Status: New
** Summary changed:
- BDM with device_type=lun fails
+ [SRU] BDM with device_type=lun fails
** Description changed:
- 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.
+ 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] for description of the
+ property's incompatibility with LUN devices
+
+ * Libvirt rejects the creation of the volume "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 points are addressed by [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 using with volume1, specifying it as a scsi lun
+ device, and the second volume
+
+ 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
+
+ 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
+
+
+ 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'
** Description changed:
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] for description of the
property's incompatibility with LUN devices
- * Libvirt rejects the creation of the volume "unsupported configuration:
- scsi-block 'lun' devices do not support the serial property"
+ * 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 points are addressed by [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 using with volume1, specifying it as a scsi lun
device, and the second volume
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
+ --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
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
-
- 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.
+ 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'
** Description changed:
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] for description of the
property's incompatibility 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 points are addressed by [2]
+ * 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 using with volume1, specifying it as a scsi lun
device, and the second volume
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
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
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'
--
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/2065084
Title:
[SRU] BDM with device_type=lun fails
Status in Ubuntu Cloud Archive:
New
Status in Ubuntu Cloud Archive caracal series:
New
Status in Ubuntu Cloud Archive dalmatian series:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Status in nova package in Ubuntu:
New
Status in nova source package in Noble:
New
Bug description:
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
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'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2065084/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list