rescuing a boot from volume instance failed with "no bootable device" when hw_rescue_bus=scsi

[Jonathan Rosser]

I spent some time understanding how to rescue instances which are boot-from-volume.

After finding a setup which would rescue instances properly with hw_rescue_device=disk and hw_rescue_bus=usb, switching the rescue bus to hw_rescue_bus=scsi resulted in an Ubuntu Focal instance to show "No bootable device" in the instance console when trying to rescue it.

Switching the bus back to USB and unrescue/rescue worked as expected.

Here is the xml from the scsi bus rescue attempt http://paste.openstack.org/show/803383/

Commands like this were used: openstack server rescue --image d0d00858-0672-4d19-9e5a-fb120d78c0fc 81057513-24cd-49e7-b1e5-939d4080bb21 --os-compute-api-version 2.87

Environment
===========
1. Exact version of OpenStack you are running.
   OpenStack Victoria, OpenStack-Ansible 22.0.0

2. Which hypervisor did you use?
   Libvirt + KVM. libvirt 6.0.0-0ubuntu8.5~cloud0

2. Which storage type did you use?
   All storage on Ceph

3. Which networking type did you use?
   Neutron with LinuxBridge

[Lee Yarwood (lyarwood)]

I've reproduced a version of this on master with a fedora 34 instance, while the rescue disk appears attached from outside the domain within the guest OS it isn't listed and this leads to the original disk being booted from:

$ sudo virsh domblklist e74f8339-6105-4d81-af75-2d3eb538dd97
 Target Source
-------------------------------------------------------------------------------------------
 vda /opt/stack/data/nova/instances/e74f8339-6105-4d81-af75-2d3eb538dd97/disk
 sda /opt/stack/data/nova/instances/e74f8339-6105-4d81-af75-2d3eb538dd97/disk.rescue

$ sudo virsh dumpxml e74f8339-6105-4d81-af75-2d3eb538dd97
[..]
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/opt/stack/data/nova/instances/e74f8339-6105-4d81-af75-2d3eb538dd97/disk.rescue' index='1'/>
      <backingStore type='file' index='3'>
        <format type='raw'/>
        <source file='/opt/stack/data/nova/instances/_base/8d5164eb9ad02055132ee054d7154d245e2c3626'/>
        <backingStore/>
      </backingStore>
      <target dev='sda' bus='scsi'/>
      <boot order='1'/>
      <alias name='scsi0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

[..]
    <controller type='scsi' index='0' model='lsilogic'>
      <alias name='scsi0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 20G 0 disk
└─vda1 252:1 0 20G 0 part /

I wonder if this is a libvirt bug with the use of <boot order='1'/>?

[wong luffy (hlhhhh)]

Is this bug have been fixed?