VM Occupancy

Sam Kirchoff

Recent changes have been made at the request of our user base to include fields in our Virtualization assessment we call VM Occupancy. However, this article will outline a few other fields that were included in this effort.

The simple definition of this is the following:

  • It only applies to Profiling VMware vCenter environments
  • Live Optics now pulls the total storage capacity and capacity used as reported by the Guest Operating System and witnessed by VMTools
  • VMTools or third party VMTools equivalent must be present for these values to be retrieved

Until recently, Live Optics reported the following capacity fields that are useful for sizing storage as they would include the total capacity being consumed on a storage array.

Virtual Disk Capacity:
Is the VM size provisioned to the VM by VMware. In other words, “how thick CAN it become.”

Virtual Disk Used:
Is the size allocated to the VM by VMware. In other words, “how thick HAS it become.”

These metrics effectively describe the container provisioned by VMware.

However, the actual capacity of the VM might be higher or lower than the Virtual Disk size that is defined by VMware for various legitimate reasons.

Most commonly capacity might be lower.

Since Virtual Machines are allowed to “Thicken” over time the Virtual Disk Used space will grow as the Guest Operating System expands the thin provisioned VM. Eventually, without maintenance, most thin provisioned VMs will expand to the total Virtual Disk Capacity as they age.

However, the Guest Operating System is maintaining its capacity inside the VM under different rules. As capacity is deleted from the Guest OS’s perspective the actual used capacity may be very different than what VMware reports as Virtual Disk Capacity used.

This delta between the actual space being consumed from the Guest OS and the Virtual Disk Used believed to be consumed by VMware is referred to as White Space.

White space is the enemy of capacity based licensing often found in the cloud or with Data Protection products. So, it’s essential that you use the right numbers.

The two new metrics being introduced here are the following:

Guest VM Disk Capacity:
This is the VMTools/OS perspective of provisioned capacity. This is what the Guest OS running in the VM thinks it has for capacity. This may be lower, but can often be equal to Virtual Disk Used.

Guest VM Disk Used:
This is the VMTools/OS perspective of the used capacity. This is what the Guest OS running in the VM thinks it has USED for capacity. This will most often be the lowest and most accurately reported value for used capacity that should be used in a sizing exercise.

Example:
In a non-storage related capacity sizing it might be more relevant to use the 25GB value vs. the 75GB

Virtual Disk Capacity

100GBs

Virtual Disk Used

75GBs

Guest VM Disk Capacity

73GBs

Guest VM Disk Used

25GBs

In this scenario there would be 50GBs of white space you don’t want to count.

In an external storage sizing exercise, one would use the 75GB value as that includes other artifacts that consume space like snapshots that will consume real space.

However, used capacity in these values can also be higher! And it’s important that you know why. It’s likely not an error. It’s a conversation!

Around 2006-2008 VMware had a LUN limitation of 2TBs and at the same time there was a growing stronghold for the use of iSCSI as a protocol to access external storage.

Linux & Microsoft Operating Systems had a disk size limitations of over 200TBs and people sought ways to circumvent the limitations of VMware as well as implement some creative architectures not otherwise achievable.   

One of the forerunners in iSCSI and iSCSI design creativity was a company Dell acquired called EqualLogic.

Regular installs would implement a technique called Guest iSCSI connections and this is wildly misunderstood as VMware RDMs, however, they are not the same.

What’s the difference?

An RDM is a disk that is created and known to VMware. It’s passed to the Guest OS. The bottom line is that VMware is aware of it.

A Guest iSCSI Disk is when the Guest OS uses its Microsoft/Linux guest iSCSI initiator to mount external storage. They key here is that VMware has NO knowledge or management of that capacity. The exception to this is that VMTools will see this capacity because it’s installed in the guest OS and talking directly to the disk management services.

The net result is that it’s entirely possible for a VM to report its capacity as much higher than the Virtual Disk Capacity numbers suggest is physically possible…and those higher numbers will likely be correct.  

Example:
The Virtual Machine referenced previously has now mounted a 500TB volume to represent as Drive E in the Windows Operating System and has use a Guest iSCSI connection technique. This creates a 1-to-1 relationship between the Guest VM OS and the external storage provider. However, the VM is only using 325GBs of the 500GBs allocated to Drive E.

In this situation, the 325GBs is real capacity and needs to be considered or the solution will be undersized. However, it will not be reflected in the Virtual Disk Used numbers provided by VMware.

Virtual Disk Capacity

100GBs

Virtual Disk Used

75GBs

Guest VM Disk Capacity

500GBs

Guest VM Disk Used

325GBs

The last scenario to watch out for is when VMTools is NOT present at all or the Virtual Machine is OFF and VMTools can be reached.

In this scenario, the Guest VM capacity values will be Zero as this data is not reported due to the lack of VMTools being accessible on the Guest VM.  

In this scenario, you would have to assume the worst-case scenario of 75GBs as the capacity value for that machine to be sure you didn’t undersize.

Virtual Disk Capacity

100GBs

Virtual Disk Used

75GBs

Guest VM Disk Capacity

0GBs

Guest VM Disk Used

0GBs

Additional values included in this release are the following.

Guest Hostname:
This is the DNS/FQDN name of the guest OS. “Guest Hostname” is what VMware calls this in their API. We didn’t come up with that slightly odd naming convention. A VM name in vCenter doesn’t have to be the actual Guest VM OS’s registered name on the network and can make identifying the machine difficult. Having the Guest Hostname will remove any ambiguity when it can be retrieved.

Active Used vs. Consumed Host memory:
In VMware terms, you have will have Active Used vs. Consumed Host memory. These definitions are best gleaned from VMware and Duncan Epping*. 

Consumed Host Memory is the amount of physical memory that has been allocated to the virtual machine. This also includes things like memory overhead, that also means that Consumed can be larger than what has been provisioned.

Active Memory more or less already explains it, it is what the VMkernel believes is currently being actively used by the VM. Now it should be pointed out here that this is an estimate calculated by a form of statistical sampling.”

Consumed Host is the total amount of memory the VM is taking from the Hypervisor that is running it.
Provisioned is what has been given to the Virtual Machine Guest OS.
Active Memory is what the Guest OS believes it is currently using.

*http://www.yellow-bricks.com/2010/12/20/vcenter-and-memory-metrics/

Was this article helpful?
1 out of 1 found this helpful
Please sign in to leave a comment.