The example above creates a layered folder structure, where you do not have to create too many of the same alarms in different places. You could think it out and use folders in folders:īy creating Datastore folders-in-folders you can configure alarms in more detail AND keep it manageble. 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. On those LUNs I can recreate the “datastore usage” alarm with a lower “high water mark” if I like. The “LUNs holding snapshots” are the LUNs where the VM configurations lie, and where the VMware snapshots land. 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. Other folders, like the “non-VI workloads” folder has the “datastore usage” alarm recreated but not the “non-VI workload detected”. 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%). Next I recreated the “Non-VI workload detected” alarm on the folder itself. You can see two alarms where disabled (these are the alarms defined on the vCenter level). In the example, I show the alarm definitions of the folder “Data LUNs”. Each folder can have different alarms created. In the example above, I created multiple folders. An example is shown below:īy creating Datastore folders you can put alarms onto Datastores in more detail. Disable the datastore alarms on the vCenter level, then create new Alarms on a folder level. The idea I had, was to use folders in the Datastore view. How to put alarms only where you want them 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). This alarm can be a problem when you have a LUN with only a single virtual disk with the full LUN size deployed. This alarm is raised whenever the available disk capacity exceeds a certain percentage. 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)Ģ) Datastore usage on disk. The two most obvious are:ġ) Non-VI workload detected on the datastore. VSphere now has its share of these alarms. 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. 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).Īn alarm is per definition only useful if it shows only when there is a real problem. This article basically states that vCenter might become unresponsive as soon as you add alarms to datastore folders. UPDATE: An anonymous commenter pointed me to this VMware KB article. Here’s how to loose these errors on certain stores while enforcing them on others. Errors like “non-VI workload detected” on your ISO LUN, “Datastore usage on disk” and so on. Very nice to have, but some of these alarms are so generic, that datastores are simply always in an alarmed state. New and improved in vSphere: Datastore alarms.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |