Ok, here are the results of the tests I performed. The TL;DR version is in a vROps 6.6.1 system upgraded directly from 6.3 using a single Windows 2012 R2 VM, I am seeing behavior as to be expected whereby vROps alerts apply on a per-drive-letter basis and not cumulatively or on a globally-summed basis. That is to say, if, like you have in your case, multiple volumes each mounted as a separate drive letter, the alerts are per-drive-letter. It is possible to have the same alert be active multiple times at multiple severity levels for the same VM object due to this. I will present a number of screenshots here, so be warned.
First thing here, the symptom definition.
This is only one of three definitions, but they're the same minus the threshold level. We're looking at the "immediate" trigger which is at 90%. I've highlighted the metric which is very specifically called "Guest File System Usage (%)". Also, the screenshot below shows the available metrics from the metric picker within this definition.
Note that you don't see that metric there.
Next, I have a VM which contains four drives lettered C, E, F, and G with sizes of 60GB, 20GB, 40GB, and 100GB, respectively.
All of the drives share the same PvSCSI controller albeit on different IDs. You can see here that, after a data collection, there are independent drive letters each with a set of metrics corresponding.
I then create an 18 GB file on drive E. This is intended to trip the "immediate" symptom definition which should then trip an alarm.
Once created and a data collection is performed, it does exactly that.
I've highlighted the metric at the very bottom of this image. The name is the same as that which was defined on the symptom definition and not any of the "Total"-based metrics.
Next, I want to test the hypothesis whereby guest file system space is considered cumulatively. I write a 35 GB file to F. The following result is as shown below.
After a collection cycle, we see the same alert has fired, but this time at a different symptom level. This is because the alarm is configured as an OR operator.
Above you can see the alert definition name, and two separate symptoms being maintained; a new one for drive F has been added with the threshold breaching 85%.
I then delete the newly-created file from drive F which returns the drive to an essentially "empty" state.
After a single collection cycle, the alarm updates once again (note the start time value and the updated time value) to remove the active symptom for drive F.
========================================================
So as I hope I've shown, the alarm and symptom definition should do what you want. Here are two other points, however:
- You cannot seem to be able to select the metric that is used to formulate the symptom definition as it does not exist.
- In case where this definition may not exist on your end, possibly due to an upgrade path where you have not reset out-of-box default content, I can envision a workaround.
- Create a temporary VM with the max number of drives you would ever encounter in your environment.
- Give them all drive labels, format, mount, etc. to present to the OS.
- After a data collection cycle, see if all those mount points show up in vROps.
- Create a new symptom definition replacing the default one and use your 5 GB threshold or whatever but add each drive as an OR condition.
- Use the metric picker but select an object rather than the default list. This will populate metrics specific to your test VM allowing you to select all the possible drive letters and the same metric for each one.
Let me know if this is of any help.