Metric Categories for Storage in vCOPs

[TheVMinator]

I am looking at the metrics available for storage for an individual VM in the Custom UI.  I see three similar categories with similar/identical metrics to choose from.

How do these categories differ for an individual VM?

• Storage
• Disk
• Virtual Disk

Does storage refer to the entire datastore that the VM is on whereas disk refers to just this VMs disks?  How is a "disk" metric different from a "virtual disk" metric for the same VM?

[NuggetGTR]

From how I have always looked at it, and from what I can tell,

Virtual disk metrics are directly related to the virtual scsi adapter(s) on the virtual machine, and the metrics relating directly with those.

Disk metrics are directly related to the raw LUN(s) naa.xxxxxx that the virtual machine disks are sitting on.

Storage I couldn't say 100% its not a vCenter metric so its produced in vCOPS and could take the previous 2 and aggregate them.

Either way the fist 2 will be similar as they are so closely tied together

[mark_j]

You need to think about what storage is. Is it a scsi id? is it a network device? These things all matter. I'm not going in to specifics here for each resource type, but I'm going to summarize for this question.

You have Virtual disk. You have Disk / Device. You have Storage. You have datastore.

Virtual disk is going to be accurate regardless of the underlying storage medium/protocol, so this is the best option for VM analysis.

Disk / Device is only going to exist for scsi-based disks.. these can be formatted as VMFS or utilized for RDM.  NFS won't be included here. This is because there IS NO underlying scsi data for a NFS location which is using file-based rather than block-based technologies.

Datastore will exist for VMFS volumes and NFS. It will not include RDMs.

Storage is a high-level attribute category that is generated by vCOps. It is accurate regardless of the storage medium/protocol/technology, however the available attribute are high-level in nature.

So, virtual disk for anything granular and storage for anything high-level for things such as planning and overall observation.

[TheVMinator]

You have Virtual disk. You have Disk / Device. You have Storage. You have datastore.

Virtual disk is going to be accurate regardless of the underlying storage medium/protocol, so this is the best option for VM analysis.

OK - just to clarify - does "virtual disk" include RDMs?  Is a pmode RDM considered a "virtual disk" and counted with these totals?

Storage is a high-level attribute category that is generated by vCOps. It is accurate regardless of the storage medium/protocol/technology, however the available attribute are high-level in nature.

When you say it is accurate regardless of the storage medium/protocol/technology, do you mean to say that it includes RDMs as well?

Thanks!

[mark_j]

Yup, virtual disk include RDMs. The reason is, the SCSI controller is bound to the VMDK and logs all performance data of that disk as if it is just another disk. The RDM may just be using a pointer file, but to the VM it doesn't know the difference from a performance stat perspective.

Yes, it includes RDMs no matter what. I said storage protcol/etc because NFS is treated differently for some of the other attribute groups like disk/devices.

If you think about it, this also causes a problem with RDM and disk space. For environments with RDMs, we need to actually turn off the disk space>allocation capacity planning  features because vCenter reports the RDM pointer files as the full RDM size, even if it's not using it.

So from a "provisioned" perspective, if you've got:

A datastore "VMFS DS1" that is 50GB large.

VM1:

Disk1 - 10gb - VMDK on VMFS DS1

Disk2 - 100gb - RDM, using pointer VMDK on VMFS DS1.

Well, vCOps looks at this and says...

Usable capacity is 50GB... ok.

VM provisioned size is 110GB.. ok.

VM used size is 10GB... ok.

Well, if you used the disk space>allocation model it'd think you're overprovisioned on that datastore and the VM is consuming 110GB and you're overcommitted by 100+ %.

However, if you use the disk space>demand model, it'll use the used size and say your VM is using 10GB.

So, one of those little things you need to be aware of if you've got RDMs. Configure you policies properly, otherwise you'll get wacky cap planning forecasting,capacity remaining,time remaining #s. If you've got VMs with thin disks mixed in to the environment AND have RDMs, then you're going to need to split up policies to ensure you're getting the right cap planning model+overcomitt settings applied to the right resources.

Too much info?