Boot volume creation failure leaves secondary volume attached to broken server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Ameed Ashour | ||
Ocata |
Fix Committed
|
Medium
|
Matt Riedemann | ||
Pike |
Fix Committed
|
Medium
|
Charlotte Han | ||
Queens |
Fix Committed
|
Medium
|
Lee Yarwood |
Bug Description
Attempt to boot a server with a block device mapping that includes a boot volume created from an image, plus an existing data volume. If the boot-volume creation fails, the data volume is left in state "in-use", attached to the server which is now in "error" state". The user can't detach the volume because of the server's error state. They can delete the server, which then leaves the volume apparently attached to a server that no longer exists. The only way out of this is to ask an administrator to reset the state of the data volume (this option is not available to regular users by default policy).
The easiest way to reproduce this is to attempt to create the boot volume from qcow2 image where the volume size is less than the image (virtual) size.
~$ cinder list
+------
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+------
| 2e733722-
+------
~$ nova boot --flavor m1.large --availability-
+------
| Property | Value |
+------
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-
| OS-EXT-STS:vm_state | building |
| OS-SRV-
| OS-SRV-
| accessIPv4 | |
| accessIPv6 | |
| adminPass | DNTr8MG3kVmC |
| config_drive | |
| created | 2016-10-
| flavor | m1.large (4) |
| hostId | |
| id | 9541b63c-
| image | Attempt to boot from volume - no image supplied |
| key_name | - |
| metadata | {} |
| name | ol4 |
| os-extended-
| progress | 0 |
| security_groups | default |
| status | BUILD |
| tenant_id | 66234fea2ccc423
| updated | 2016-10-
| user_id | b2ae6b7bdac142d
+------
~$ cinder list
+------
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+------
| 2e733722-
| a5a9f27b-
+------
~$ cinder list
+------
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+------
| 2e733722-
| a5a9f27b-
+------
~$ nova volume-detach 9541b63c-
ERROR (Conflict): Cannot 'detach_volume' instance 9541b63c-
~$ nova delete 9541b63c-
Request to delete server 9541b63c-
~$ nova list
+----+-
| ID | Name | Status | Task State | Power State | Networks |
+----+-
+----+-
~$ cinder list
+------
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+------
| 2e733722-
| a5a9f27b-
+------
~$ nova show 9541b63c-
ERROR (CommandError): No server with a name or ID of '9541b63c-
summary: |
- Boot volume creation leaves secondary volume attached to broken server + Boot volume creation failure leaves secondary volume attached to broken + server |
Changed in nova: | |
assignee: | nobody → Lee Yarwood (lyarwood) |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in nova: | |
assignee: | nobody → Raghad Qutteneh (raghadq) |
Changed in nova: | |
assignee: | Raghad Qutteneh (raghadq) → Ameed Ashour (ameeda) |
status: | Confirmed → In Progress |
tags: | added: volumes |
Changed in nova: | |
assignee: | Ameed Ashour (ameeda) → Matt Riedemann (mriedem) |
Changed in nova: | |
assignee: | Matt Riedemann (mriedem) → Ameed Ashour (ameeda) |
Just ran into this while looking at another bug. Specifying a pysical_block_size doesn't seem to work any longer so you end up with a boot failure. The annoying things are that first off even though boot failed the Instance is listed as Active and Up, and then after deteting the failure, and deleting the Instance as reported in this bug the volume is never detached.
Looking at the logs it appears that the cleanup never issues any of the Cinder calls to clean things up.