[Bug 2054446] Re: [SRU] Boot from ISO does not work

Thu Aug 21 17:15:03 UTC 2025

Hello Pavlo, or anyone else affected,

Accepted nova into noble-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/nova/3:29.2.0-0ubuntu1.1 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
noble to verification-done-noble. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-noble. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: nova (Ubuntu Noble)
       Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-noble

-- 
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:
  Fix Committed
Status in nova source package in Oracular:
  Won't Fix
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 such cases, you can refer to the steps in the [Test Plan]
  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