Mitaka Resize VMware Ephemeral Root Disk -> Internal Server Error 500
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Confirmed
|
Low
|
Unassigned |
Bug Description
Description
===========
I am observing an internal server error when trying to resize the root disk.
The error is: 'NoneType' object has no attribute 'backing'
"nova/virt/
As I see it, it is caused by the assumption, that the root disk is named after the UUID here:
https:/
To my knowledge, that is not generally the case, and VSphere quite happily renames it (e.g after a Storage VMotion, which may happen automatically, when the ephemeral storage is in a SDRS cluster).
In my case, the root disk is actually named <uuid>-00001.vmdk, resulting (presumably) in the following:
root_disk= '<uuid>.vmdk'
There is no backing of the file,
root_device = None
And given those two variables (https:/
Resulting in vmdk.device = None (the same as root_device) here
https:/
Steps to reproduce
==================
* Create Instance
* Trigger Storage VMotion to a different datastore (there are possibly different ways to cause the rename)
* Resize the ephemeral root device
Expected result
===============
* The VM is running with a resized root disk
Actual result
=============
The following error message:
Message:'NoneType' object has no attribute 'backing'
Code: 500
Details: File "/var/lib/
Environment
===========
VSphere 6.0
Two ephemeral datastores on VMFS 5 (FcoE), not in a SDRS Cluster
Own Kolla Build from mitaka/stable (be033eef7296d1
tags: | added: vmware |
Changed in nova: | |
status: | New → Confirmed |
importance: | Undecided → Low |
If I am not mistaken, I can take care of fixing the bug, and submit a patch proposal.
Is there any reason, why not the first disk on the first controller is taken?