rescuing a boot from volume instance failed with "no bootable device" when hw_rescue_bus=scsi
| 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_
Switching the bus back to USB and unrescue/rescue worked as expected.
Here is the xml from the scsi bus rescue attempt http://
Commands like this were used: openstack server rescue --image d0d00858-
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.
2. Which storage type did you use?
All storage on Ceph
3. Which networking type did you use?
Neutron with LinuxBridge
| Lee Yarwood (lyarwood) wrote | #1 |
| Changed in nova: | |
| status: | New → Confirmed |
| assignee: | nobody → Lee Yarwood (lyarwood) |
| importance: | Undecided → Medium |
| wong luffy (hlhhhh) wrote | #2 |
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-
Target Source
-------
vda /opt/stack/
sda /opt/stack/
$ sudo virsh dumpxml e74f8339-
[..]
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='/
<backingStore type='file' index='3'>
<format type='raw'/>
<source file='/
<
<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'/>?