This new memory consumed model through me for a loop at first, when I looked at memory workload for my host, I couldn't figure out why the host demand was so much higher than host usage and virtual machine demand. Then speaking with members from our vRealize Operations development and technical marketing team, they educated me on the change to a memory consumed model and that it was labeled under Memory, as show in the image below.
I was looking at the legend which still indicated demand and to me that was active memory. After that was cleared up, I recognized another issue, when I powered down all the hosts in a cluster there was still host demand and the demand was the same amount as the overhead. Notice in the picture below, both components are reading 1.47 GB.
That is because according to the Memory Counters Reference Guide, consumed memory includes memory used by the service console, the VMkernel, vSphere services, plus the total consumed metrics for all running virtual machines. Unfortunately, we are double counting the overhead. On my lab host, overhead is 19.37% of the allocated resources, there is an additional 19.37% being added because of the consumed memory model; which makes it appear that there is much higher memory consumption than is actually happening on the host. A side affect is that it will trigger alerts early.
This is easily noticeable when navigating to All Metrics and selecting ESX System Usage (KB) and the Consumed (KB). The first image shows the ESX System Usage (KB) at 1,544,011.75.
The second image shows Consumed (KB) at 1,544,011.75. The Consumed (KB) drops to match the static ESX System Usage (KB) after the virtual machines have been powered down. Both are observing the memory used by the service console, the VMkernel, and vSphere services.
From the Performance tab on the vSphere Web Client, consumed memory never goes all the way down, whereas active and granted drop to near zero. The consumed memory in the vSphere Web Client is reading 1,542,468 for the latest reading.
There is a pretty easy fix, update your default policy to use Overcommit CPU and use true memory demand; which was the default policy up until vRealize Operations 6.1.
After you have made the change and return to the host memory workload, it will look like it did in prior version.
I have worked with our R&D team on this issue, they are currently researching it further and we should have an update in an upcoming release.
*Note: If you performed an upgrade, it keeps the default policy for Overcommit CPU and use true memory demand.