VMdamentals.com

New and improved in vSphere: Datastore alarms. Very nice to have, but some of these alarms are so generic, that datastores are simply always in an alarmed state. Errors like “non-VI workload detected” on your ISO LUN, “Datastore usage on disk” and so on. Here’s how to loose these errors on certain stores while enforcing them on others.

UPDATE: An anonymous commenter pointed me to this VMware KB article. This article basically states that vCenter might become unresponsive as soon as you add alarms to datastore folders. So I guess it is wise not to add any alarms at this time to the datastores (My test environment hasn’t developed a problem yet though).



Why some alarms don’t matter

An alarm is per definition only useful if it shows only when there is a real problem. If everyone’s car alarm would activate each and every day, soon no one will bother to even look up from their work if they hear an alarm go off.

vSphere now has its share of these alarms. The two most obvious are:

1) Non-VI workload detected on the datastore. This alarm is raised whenever vCenter detects an I/O load or capacity usage which is not under control of vCenter (for example when you place ISO images on a LUN)
2) Datastore usage on disk. This alarm is raised whenever the available disk capacity exceeds a certain percentage. This alarm can be a problem when you have a LUN with only a single virtual disk with the full LUN size deployed.

In the above examples, you are aware of the “problem” so you do not want to see alarms on these “problems”: You know you have ISO files on certain LUNs, and you know you filled up a LUN to 99.9% without risk (given the fact you do not put snapshot files on that particular LUN).



How to put alarms only where you want them

The idea I had, was to use folders in the Datastore view. Disable the datastore alarms on the vCenter level, then create new Alarms on a folder level. An example is shown below:

            By creating Datastore folders you can put alarms onto Datastores in more detail.



In the example above, I created multiple folders. Each folder can have different alarms created. In the example, I show the alarm definitions of the folder “Data LUNs”. You can see two alarms where disabled (these are the alarms defined on the vCenter level). Next I recreated the “Non-VI workload detected” alarm on the folder itself. This effectively monitors all datastores in that folder for non-VI workloads, but it does not check disk space (that is because all my data LUNs are actually filled up to 99.9%).

Other folders, like the “non-VI workloads” folder has the “datastore usage” alarm recreated but not the “non-VI workload detected”. So all datastores in that folder are monitored for unwanted filling up of the LUN, but non-VI workloads will not be a reason for an alarm.

The “LUNs holding snapshots” are the LUNs where the VM configurations lie, and where the VMware snapshots land. On those LUNs I can recreate the “datastore usage” alarm with a lower “high water mark” if I like.



Folders-in-folders

Using a single layered folder structure has one caveat: The more folders you build, the more rules you’ll have to recreate, often even multiple times. You could think it out and use folders in folders:

            By creating Datastore folders-in-folders you can configure alarms in more detail AND keep it manageble.



The example above creates a layered folder structure, where you do not have to create too many of the same alarms in different places. It is a bit harder to read, but you can still see the ISO-LUN is monitored on data usage only, while the data LUNs are monitored on non-VI workload only etc.

Once you configure the above, you should not see any Datastore alarms come up any more – unless there really IS a problem!

One Response to “Rid yourself of superfluous vCenter datastore alarms”