Unrescue assumes swap disk is always returned as first disk
Bug #919461 reported by
Rick Harris
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Expired
|
Low
|
Unassigned |
Bug Description
This isn't necessarily a bug, but rather a placeholder tix to investigate a dubious assumption in the code.
Currently, unrescue queries for VBDs related to the instance and then assumes that the second VBD will always be the root fs.
This seems to work, but it would be a good idea to understand exactly why this works (it's not obvious AFAICT).
A safer approach would be to use the name-labels on the vbd to determine which is the root vs swap disk.
Changed in nova: | |
importance: | Undecided → Low |
status: | New → Confirmed |
To post a comment you must log in.
I am making the assumption that we are looking at this for XenServer as referenced by the term VBDs additionally, for this assessment of what is being done with Nova i was looking at trunk. With XenServer, the unrescue process seems to start by looking for the instance name + "-rescue" from information which was provided to the method. The lookup then queries the xenapi for the VM by name label which returns VM reference information. Once the VM is found, the instance information is set as an object using the same lookup method as was done initially just without the "-rescue" string, this sets the original instance information.
When the rescue VM goes to be destroyed, the rescue VM is shutdown, or at least force shutdown if need be. VDI references are looked up using the rescue VM information and then the root VDI is looked up using the original VM information. the VDI references are then compared and the VDIs, which are NOT the "root_fs", are then safely destroyed. Finally, the rescue VM is destroyed and the original VM has it's boot block released and it's restarted.
In short, nova is using name labels for lookups now, however, based on this commit : https:/ /github. com/openstack/ nova/commit/ 859172963f5e1f9 2682c06f603262e 234ea14a58 : it seems like this may have been the case when this was originally posted. Presently, I am not sure if we have anything that would need fixing and or work. We could attempt to walk through nova and make the lookup of VBD's, VDI's and VHD's more intelligent but I am not sure it needs doing at present. thoughts?