[Bug 2054446] Re: [SRU] Boot from ISO does not work
Hua Zhang
2054446 at bugs.launchpad.net
Wed Jun 25 08:26:32 UTC 2025
** Description changed:
[Impact]
Pure ISO image cannot be booted even though
CVEs(https://review.opendev.org/c/openstack/ossa/+/923301/1/ossa/OSSA-2024-001.yaml)
are already supported.
+
+
+ [Test Plan]
+
+ To verify this functionality manually, you can follow these steps (see
+ also comment https://bugs.launchpad.net/cloud-
+ archive/+bug/2054446/comments/21 for more details):
+
+ 1. Upload a pure iso image (eg: a veeam server recovery iso for windows
+ mentioned in the comment
+ https://bugs.launchpad.net/nova/+bug/2054446/comments/8) using the '--
+ disk-format iso' option:
+
+ openstack image create --public --file ~/images/veeamwindows.iso
+ --disk-format iso veeamwindows.iso
+
+ 2, Boot an VM using this pure iso image:
+
+ openstack server create --wait --image veeamwindows.iso --flavor
+ m1.small --key-name mykey --nic net-id=$(openstack network show private
+ -fvalue -cid) i1
+
+ 3, Check the libvirt xml configuration of the VM to confirm that the
+ disk device type is set to cdrom:
+
+ $ sudo virsh dumpxml 1 |grep '<disk'
+ <disk type='file' device='cdrom'>
+
+ 4, Optionally, access the vnc console to further verify that the iso boots correctly.
+
[Where problems could occur]
ISO+MBR/GPT multiple images can be booted in disk mode with CVE
detection support. However, a pure ISO single image can only be booted
in cdrom format. cdrom mode remains unsupported without this fix even if
CVEs are already supported since Bobcat release.
- [Test Case]
+ There are two patches involved: the deepcopy patch
+ (https://review.opendev.org/c/openstack/nova/+/920374) and the iso patch
+ (https://review.opendev.org/c/openstack/nova/+/909611).
- Pls refer to [Test steps] section below.
+ The deepcopy patch primarily ensures that copy.deepcopy() is used when
+ handling BlockDeviceMapping objects. If a regression occurs, whether in
+ BlockDeviceMapping or DriverBlockDevice logic, these cases are already
+ covered by unit tests, so any regression issues should be reported by
+ autopkgtests.
- [Regression Potential]
+ The iso patch mainly adds support for booting pure iso images in cdrom
+ mode. If a regression occurs, this functionality may no longer work as
+ expected. In suce cases, you can refer to the steps in the [Test steps]
+ section to verify it.
- There are two patches, one is deepcopy patch(https://review.opendev.org/c/openstack/nova/+/920374), introduced since 30.0.0;
- the other one is iso patch(https://review.opendev.org/c/openstack/nova/+/909611), introduced since 31.0.0
- The fixes are already in the upstream main, epoxy(2025.1), need to backport to dalmatian(2024.2), caracal(2024.1), bobcat(2023.2)
-
- I have tested this fix, it worked fine -
- https://bugs.launchpad.net/cloud-archive/+bug/2054446/comments/21
-
- Regressions will likely show up when attempting to boot ISO images, as
- well as when using BlockDeviceMapping and DriverBlockDevice instances.
- Both of these cases are covered under the package's unit tests, so
- autopkgtests should report any issues.
[Others]
+ The deepcopy patch has been introduced since 30.0.0, and the iso patch since 31.0.0
+ These fixes are already present in the upstream main, epoxy(2025.1), they need to be backported to dalmatian(2024.2), caracal(2024.1), bobcat(2023.2)
+
Original Bug Description Below
===========
It may be https://bugs.launchpad.net/nova/+bug/1454901 resurfacing
again..
Symptoms using fresh DevStack/master:
I follow the docs https://docs.openstack.org/nova/latest/user/launch-instance-using-ISO-image.html
and using tinycore iso for testing http://tinycorelinux.net/ (this is very small liveCD ISO) to speed up testing.
Image is created with
openstack image create --public --file Core-14.0.iso --disk-format iso
Core-14.0.iso
Then I boot the instance as usual
openstack --os-compute-api-version 2.latest server create --image
Core-14.0.iso --flavor cirros256 --no-network iso-test
The instance is ACTIVE, but when I connect to it via noVNC it shows that
it failed to boot - "No bootable device"
The relevant part of the instance XML is
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/opt/stack/data/nova/instances/0c3d31a9-7ecf-4625-9e0e-4cd89d1b76c2/disk' index='1'/>
<backingStore type='file' index='2'>
<format type='raw'/>
<source file='/opt/stack/data/nova/instances/_base/b2b7eb374cc75a24d0e5ba0eca7ca9cc1e6dc7c6'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</disk>
This is Nova/master + libvirt 8.0
I checked the same on OpenStack Antelope - the result is the same.
However, on OpenStack Queens (+ libvirt 4.0) the instance boots from the
same ISO image uploaded to Glance just fine! The relevant part of
libvirt domain XML in OpenStack Queens is
<devices>
<emulator>/usr/bin/kvm-spice</emulator>
<disk type='file' device='cdrom'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/var/lib/nova/instances/791cf357-02e6-4a7f-9310-25f5e79cf27d/disk'/>
<backingStore type='file' index='1'>
<format type='raw'/>
<source file='/var/lib/nova/instances/_base/d646a5bfc2ce7e3926d0f368b8adb975b245cfd2'/>
<backingStore/>
</backingStore>
<target dev='hda' bus='ide'/>
<readonly/>
<alias name='ide0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
Notice the difference in disk device and target/address/alias. When I
manually edited the XML on devstack to look like that from Queens, the
instance booted successfully.
This looks like a regression somewhere in Nova (libvirt driver?)
-
- [Test steps]
-
- Pls refer to the comment (https://bugs.launchpad.net/cloud-
- archive/+bug/2054446/comments/21) for specific test steps.
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/2054446
Title:
[SRU] Boot from ISO does not work
Status in Ubuntu Cloud Archive:
Fix Released
Status in Ubuntu Cloud Archive bobcat series:
New
Status in Ubuntu Cloud Archive caracal series:
New
Status in Ubuntu Cloud Archive dalmatian series:
New
Status in Ubuntu Cloud Archive epoxy series:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Status in nova package in Ubuntu:
Fix Released
Status in nova source package in Noble:
In Progress
Status in nova source package in Oracular:
In Progress
Status in nova source package in Plucky:
Fix Released
Bug description:
[Impact]
Pure ISO image cannot be booted even though
CVEs(https://review.opendev.org/c/openstack/ossa/+/923301/1/ossa/OSSA-2024-001.yaml)
are already supported.
[Test Plan]
To verify this functionality manually, you can follow these steps (see
also comment https://bugs.launchpad.net/cloud-
archive/+bug/2054446/comments/21 for more details):
1. Upload a pure iso image (eg: a veeam server recovery iso for
windows mentioned in the comment
https://bugs.launchpad.net/nova/+bug/2054446/comments/8) using the '--
disk-format iso' option:
openstack image create --public --file ~/images/veeamwindows.iso
--disk-format iso veeamwindows.iso
2, Boot an VM using this pure iso image:
openstack server create --wait --image veeamwindows.iso --flavor
m1.small --key-name mykey --nic net-id=$(openstack network show
private -fvalue -cid) i1
3, Check the libvirt xml configuration of the VM to confirm that the
disk device type is set to cdrom:
$ sudo virsh dumpxml 1 |grep '<disk'
<disk type='file' device='cdrom'>
4, Optionally, access the vnc console to further verify that the iso boots correctly.
[Where problems could occur]
ISO+MBR/GPT multiple images can be booted in disk mode with CVE
detection support. However, a pure ISO single image can only be booted
in cdrom format. cdrom mode remains unsupported without this fix even
if CVEs are already supported since Bobcat release.
There are two patches involved: the deepcopy patch
(https://review.opendev.org/c/openstack/nova/+/920374) and the iso
patch (https://review.opendev.org/c/openstack/nova/+/909611).
The deepcopy patch primarily ensures that copy.deepcopy() is used when
handling BlockDeviceMapping objects. If a regression occurs, whether
in BlockDeviceMapping or DriverBlockDevice logic, these cases are
already covered by unit tests, so any regression issues should be
reported by autopkgtests.
The iso patch mainly adds support for booting pure iso images in cdrom
mode. If a regression occurs, this functionality may no longer work as
expected. In suce cases, you can refer to the steps in the [Test
steps] section to verify it.
[Others]
The deepcopy patch has been introduced since 30.0.0, and the iso patch since 31.0.0
These fixes are already present in the upstream main, epoxy(2025.1), they need to be backported to dalmatian(2024.2), caracal(2024.1), bobcat(2023.2)
Original Bug Description Below
===========
It may be https://bugs.launchpad.net/nova/+bug/1454901 resurfacing
again..
Symptoms using fresh DevStack/master:
I follow the docs https://docs.openstack.org/nova/latest/user/launch-instance-using-ISO-image.html
and using tinycore iso for testing http://tinycorelinux.net/ (this is very small liveCD ISO) to speed up testing.
Image is created with
openstack image create --public --file Core-14.0.iso --disk-format iso
Core-14.0.iso
Then I boot the instance as usual
openstack --os-compute-api-version 2.latest server create --image
Core-14.0.iso --flavor cirros256 --no-network iso-test
The instance is ACTIVE, but when I connect to it via noVNC it shows
that it failed to boot - "No bootable device"
The relevant part of the instance XML is
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/opt/stack/data/nova/instances/0c3d31a9-7ecf-4625-9e0e-4cd89d1b76c2/disk' index='1'/>
<backingStore type='file' index='2'>
<format type='raw'/>
<source file='/opt/stack/data/nova/instances/_base/b2b7eb374cc75a24d0e5ba0eca7ca9cc1e6dc7c6'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</disk>
This is Nova/master + libvirt 8.0
I checked the same on OpenStack Antelope - the result is the same.
However, on OpenStack Queens (+ libvirt 4.0) the instance boots from
the same ISO image uploaded to Glance just fine! The relevant part of
libvirt domain XML in OpenStack Queens is
<devices>
<emulator>/usr/bin/kvm-spice</emulator>
<disk type='file' device='cdrom'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/var/lib/nova/instances/791cf357-02e6-4a7f-9310-25f5e79cf27d/disk'/>
<backingStore type='file' index='1'>
<format type='raw'/>
<source file='/var/lib/nova/instances/_base/d646a5bfc2ce7e3926d0f368b8adb975b245cfd2'/>
<backingStore/>
</backingStore>
<target dev='hda' bus='ide'/>
<readonly/>
<alias name='ide0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
Notice the difference in disk device and target/address/alias. When I
manually edited the XML on devstack to look like that from Queens, the
instance booted successfully.
This looks like a regression somewhere in Nova (libvirt driver?)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2054446/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list