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

Bug #1347039 reported by zhu zhu on 2014-07-22
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Undecided
Unassigned

Bug Description

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
+---------------------------+-------------

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

Changed in nova:
assignee: nobody → zhu zhu (zhuzhubj)
status: New → In Progress
Tracy Jones (tjones-i) on 2014-07-28
Changed in nova:
importance: Undecided → Medium
zhu zhu (zhuzhubj) on 2014-07-29
tags: added: vmware
Yaguang Tang (heut2008) on 2014-08-29
tags: added: icehouse-backport-potential

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.

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

Changed in nova:
status: In Progress → Confirmed
assignee: zhu zhu (zhuzhubj) → nobody
Changed in nova:
status: Confirmed → In Progress
assignee: nobody → Timofey Durakov (tdurakov)
Radoslav Gerganov (rgerganov) wrote :

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.

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

Changed in nova:
status: In Progress → Confirmed
Jay Pipes (jaypipes) on 2015-09-21
Changed in nova:
assignee: Timofey Durakov (tdurakov) → nobody
Alan Pevec (apevec) on 2015-11-24
tags: removed: icehouse-backport-potential

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

Changed in nova:
importance: Medium → Undecided
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers