VMWare: available disk spaces(hypervisor-list) only based on a single datastore instead of all available datastores from cluster

[zhu zhu]

Currently the with vmware backend nova hypervisor-list.
The local_gb, free_disk_gb, local_gb_used are not displaying correct values if the compute node(cluster) have more than 1 datastores. Currently the code only report the resource update picking up the first datastore which is incorrect.

The real situation is for example, 20 datastores availabel for the compute cluster node, but it only calculate the 1 for resource report. Which will cause easily deployment failure saying no freespace, in fact there are enough disk for vm deployments.

[root@RegionServer1 nova]# nova hypervisor-show 1 +---------------------------+----
| Property | Value +---------------------------+-----
| cpu_info_model | ["Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU
     X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz", "Intel(R) Xeon(R) CPU X5675 @ 3.07GHz"] | | cpu_info_topology_cores | 156
| cpu_info_topology_threads | 312
| cpu_info_vendor "IBM"]
| current_workload | 0
| disk_available_least | -
| free_disk_gb | -2682
| free_ram_mb | 1545886
| host_ip | 172.18.152.120
| hypervisor_hostname | domain-c661(BC1-Cluster)
| hypervisor_type | VMware vCenter Server
| hypervisor_version | 5001000
| id | 1
| local_gb | 1799
| local_gb_used | 4481
| memory_mb | 1833630
| memory_mb_used | 287744
| running_vms | 281
| service_host | RegionServer1
| service_id | 6
| vcpus | 312
| vcpus_used | 281
+---------------------------+-------------

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/108777

[zhu zhu (zhuzhubj)]

https://review.openstack.org/108777

[OpenStack Infra (hudson-openstack)]

Change abandoned by Sean Dague (<email address hidden>) on branch: master
Review: https://review.openstack.org/108777
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Davanum Srinivas (DIMS) (dims-v)]

Removing "In Progress" status and assignee as change is abandoned.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/158815

[Radoslav Gerganov (rgerganov)]

The bug description is not entirely correct. It is true that we don't report the "actual" aggregated storage but doing so will lead to the following problem: suppose that you have two datastores each with 10GB free space and you try to deploy 15GB image. The driver will report 20GB space but spawn() will fail because there is no datastore that can hold the image.

The current behavior is that we always report the largest free space from the available datastores. This guarantees that deployment will not fail because of disk space.

The only way to fix this is to make the scheduler aware of aggregated storage and drivers to report largest free space for deployment and aggregated free space for stats. Until we have this I believe it is better to report largest free space instead of aggregated free space.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Timofey Durakov (<email address hidden>) on branch: master
Review: https://review.openstack.org/158815
Reason: base on Radoslav Georganov comments, better to fix stats issue another way

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY