The name VCPUs (total) of Hypervisors is confusing

Yep, we could be more clear here.

Not seeing the behavior with nova api:

RESP BODY: {"hypervisor_statistics": {"count": 1, "vcpus_used": 1, "local_gb_used": 10, "memory_mb": 4096, "current_workload": 1, "vcpus": 2, "running_vms": 1, "free_disk_gb": 15, "disk_available_least": 0, "local_gb": 25, "free_ram_mb": 3072, "memory_mb_used": 1024}}

Is it possible to have a screen shot and a corresponding nova api call? It is not clear if the problem is a display bug.

Hi,

I think the issue is a Nova one, for instance, according to nova.virt.libvirt.driver.LibvirtDriver.get_vcpu_total() function the
computation of the total vcpus for an hypervisor doesn't take into account the cpu allocation ratio.

Here is a screenshot which illustrate the issue.

What do you think about ?

By the way, we can observe the same behaviour for "RAM (total)" column.

As icehouse will release recently, so I think it was better to do some improvement in next version for this issue

It looks like the hypervisor API lists vcpus and vcpus used, but what it is really returning is CPUs and vcpus_used. This is a good candidate for the API formally known as V3.

Agreed we should fix this in Juno in Nova with for the API formally known as V3 (might be a good testcase for the first microversion!)

Did this get any attention in Juno, in the end?

This is really a UX feature addition

Without this fix, we don't have real knowledge how many VCPUs are available when using:

nova hypervisor-stats
nova hypervisor-show

According to the resolution on this blueprint[0], nova won't be doing changes to their API. Is there something I could do to improve the UX in Horizon?

[0] https://review.openstack.org/#/c/98058/

Hi,

I agree that it isn't a bug (it's a feature) and that the current Horizon behavior may cause misunderstood in some administrators.

As an example, the VMWare vSphere client shows the following values for disk overcommiting:

- Total space: Storage space times the overcommiting ratio;
- Real total space: Storage space (without considering any overcommiting);
- Used space: Sum of user disk spaces;
- Real used space: Real space, less then used space, since thin provisioned images (and CoW) reduces space.

I don't how how to put all these informations in the Horizon interface.

As a ideia, we could show both concepts (physical total and total with overcommit) in the interface.

The attached image represents the ideia.

It could appear at the screen after the user click in a "more", "advance" or "detailed" button at the screen.

I'm confused about the behaviour. Are you saying that nova API will always return the incorrect value for vpcu from now on? This is intentional to return the incorrect value? How would an upstream VNFM or Orchestration know how much vcpu is really available? This doesn't sound like a UX issue to me if the data source is feeding wrong info.

My understanding is what is being suggested is that if field(s) to return the total available VCPU/RAM counts factoring in overcommit are desired (or to return the ratios themselves somewhere), then they should be added as net new to the API. The existing fields to return the totals were not designed to factor in the overcommit and never have been, one assumes because this is a scheduler side setting so neither the hypervisor nor the api service actually knew what the overcommit was and thus had no ability to factor it in even if they wanted to (recent changes to help with issues in claim processing may help here).

The main source of confusion is the naming of the field as vcpus when really it is just physical cpus (for which the correct value is in fact being returned). The RAM values seem to confuse people less even though it behaves exactly the same way because the naming isn't as misleading.

Naming VCPUs to physical CPUs in Horizon UI may be concern of Horizon, but there should be an API to get overcommit ratio of physical cpus. Either each flavour or a global config value may contain this ratio but some API is needed to get this setting.

Additionally, if "vcpus" in response body shows the number of physical cpus then its name should be changed to an unambigious one (vcpus sounds like it is the number of virtual cpus). If it is really the number of virtual cpus as its name sounds, then its value should be updated with overcommit ratio parameter.

I think this should be considered a flaw in Nova, this is similar to the issue where the resource_tracker in Nova counts Cinder volumes as local hypervisor storage as I have tried addressing however doesn't seem like nobody wants to take a strong grip on these issues.

It might not be a functional flaw but it's very misleading and providing the wrong statistics is just annoying.

Both these issues should be brought up properly in meetings and be addressed, I have heard this was gonna be fixed when the resource-objects BP lands in Nova[1] however I've worked for fixes on this for liberty but it did not make it into master nor liberty. So fixing this in master and back porting to Liberty and now Mitaka should be prioritized.

[1] Think it's this one: https://github.com/openstack/nova-specs/blob/master/specs/liberty/approved/resource-objects.rst

CONFIRMED FOR: LIBERTY

Unfortunately same can be seen in Mitaka version.Seems this is not fixed

This seems to be still an issue in pike release. please consider rescheduling this as it is totally confusing.

I'm confused as to why this is relating to the cinder-backup charm. I'll set to incomplete to solicit further info..

One more example: let's use hw:cpu_policy='dedicated'/hw:cpu_thread_policy='isolate' extra specs and launch as many instances as possible in 3 hosts (8 vcpus each, HT enabled). Finally "openstack hypervisor stats show" displays:

+----------------------+-------+
| Field | Value |
+----------------------+-------+
| count | 3 |
...
| running_vms | 6 |
| vcpus | 24 |
| vcpus_used | 12 |
+----------------------+-------+

At this point no more instances can be launched with the same flavor (at least in my case) because NUMATopologyFilter doesn't give any suitable hosts. This is OK but vcpus/vcpus_used values are quite confusing because they give an impression that only 50% of CPU resources are used.