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

Bug #1918292 reported by Jonathan Rosser
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Confirmed
Medium
Lee Yarwood

Bug Description

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

Revision history for this message
Lee Yarwood (lyarwood) wrote :

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'/>?

Lee Yarwood (lyarwood)
Changed in nova:
status: New → Confirmed
assignee: nobody → Lee Yarwood (lyarwood)
importance: Undecided → Medium
Revision history for this message
wong luffy (hlhhhh) wrote :

Is this bug have been fixed?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.