VMware vCenter Driver failed to extend virtual disk while booting new VM
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Invalid
|
High
|
Unassigned |
Bug Description
How to produce this bug:
Compute driver: VMwareVCDriver
vSphere API 5.1,
VMware use: Administrator
Image: sparse type with ide controller.
Confiure in nova.conf: linked_clone =True.
Boot vm with “root_disk_size” (Example: 20GB)> “image_
If it’s first time to do this kind of vm booting, then lead to a booting failure.
Then, try to boot a second VM with the same image and flavor of first booting, you will success this time.
I noticed that vm booting failed in the virtual disk extending phase.
… In this phase:
If there is no virtual disk cache(virtual disk with the targeted image and root disk size) in this host,
and “root_disk_size” (defines in flavor, Example: 20GB)> “image_
then go to the virtual disk extending phase.
Tasks of virtual disk extending phase:
1) Invoke virtual disk extending task (t_1) to do the disk extending thing.
2) Make one additional task (t_2) to check the status(queued, running, error, success) of task (t_1).
Task (t_2) failed with an error, and this error causes the vm booting process to fail.
So, this causes the first VM booting failed.
But, there is no clean job to clear the (t_1) task, so the virtual disk will still in extending, and at last(very fast without zero formatting) this extending will success.
So, the second time we boot VM with the same image and flavor of the previous booting, the extended virtual disk(cache) is already there.So, that’s why I successed in the second booting.
I think the following code causes this issue:
def _poll_task(self, task_ref, done):
"""Poll the given task, and fires the given Deferred if we
get a result.
"""
try:
If task_info is None, then checking status of the task will cause exception, and we just log and reraise it in the upper caller. So lead to VM booting process failed.
tags: | added: vmware |
Changed in nova: | |
importance: | Undecided → High |
Changed in nova: | |
assignee: | nobody → Fan Guo (faguo) |
Changed in nova: | |
status: | New → In Progress |
Changed in nova: | |
status: | In Progress → Invalid |
assignee: | Fan Guo (faguo) → nobody |
This looks interesting. I am not met this issue before. Do you mean the _wait_for_task failure cause boot failure. And the _wait_for_task failure is due to can not get task information. Currently I don't see cases for the task.info couldn't be retrieved?
Are you using Flat images for testing?