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:

Datastore folders for alarms in more detail
            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:

Datastore folders-in-folders for alarms in more detail
            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.

Categories: VMWare

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Microsoft

Microsoft Virtual Academy- Microsoft Virtualization for VMware Professionals – VDI

http://www.microsoftvirtualacademy.com/training-courses/microsoft-virtualization-for-vmware-professionals-vdi

VMWare

VMWare Support: vSphere Command-Line Interface Documentation

https://www.vmware.com/support/developer/vcli/

VMWare

VMware View – Installing View Connection Broker

Installing a basic View 3 environment is a fairly straight forward process.