Getting into scripting can be daunting. It’s easier to just use existing scripts found online, but if you choose this route you’ll quickly run into limitations. If you take the time to learn how to create your scripts, trust me, you’ll never look back!
Automating vSphere is particularly useful for countless applications and the best way is through PowerCLI – a version of PowerShell developed specifically for VMware. Learn how to develop your own PowerCLI scripts with this free 100+ page eBook from Altaro, PowerCLI: The Aspiring Automator’s Guide.
Written by VMware vExpert Xavier Avrillier, this eBook presents a use-case approach to learning how to automate tasks in vSphere environments using PowerCLI. We start by covering the basics of installation, set up, and an overview of PowerCLI terms. From there we move into scripting logic and script building with step-by-step instructions of truly useful custom scripts, including how to retrieve data on vSphere objects; display VM performance metrics; how to build HTML reports and schedule them; the basics on building functions; and more!
Stop looking at scripts online in envy because you wish you could build your own scripts.
Alarms in vSphere are notifications that are generated when selected events occur, or conditions and states are met. There are a number of predefined alarms within vCenter Server that monitor datacentres, clusters, hosts, virtual machines, datastores, and networks. When an alarm is triggered an action can be configured to automatically respond, this could be something such as sending an email alert, or running a script.
Alarms are automatically inherited from objects higher up in the vSphere hierarchy, for example alarms configured at datacentre level apply to all clusters, hosts, virtual machines within that datacentre. The top level is the vCenter Server, alarms configured here monitor all applicable objects in the vCenter.
In this post we will quickly go over how to setup an alert for an event logged by vSphere for which a predefined alert does not already exist. This is done by creating a custom alert using the EventTypeId as the trigger event.
The first thing we need to do is get the EventTypeId, this differs from the fully formatted message you see in vSphere. Open a PowerCLI window and type Connect-VIServer where is the name of the vCenter Server to connect. Use the Get-VIEvent Cmdlet to view events with the syntax below to narrow the results.
-Entity where is the virtual machine, host, resource pool, etc. you want to view events for.
-Start where is the start date to retrieve events from, this should be in dd/mm/yyyy format (or mm/dd/yyyy if using US regional settings).
-Finish where is the end date to retrieve events from, this should be in dd/mm/yyyy format (or mm/dd/yyyy if using US regional settings).
-MaxSamples where is the number of events to retrieve. The default value is 100.
-Types where is the type of event to list, valid values are error, info, and warning.
-Username where is the user that has initiated the events you want to retrieve.
You don’t have to use all of the above. The example below will list the last 10 events on Host1 that were initiated by firstname.lastname@example.org.
The output for each event should look something like this. Locate the EventTypeId and make a note of it.
Log into the vSphere web client and browse to the level for which you want to apply the alarm, for example vCenter, host, virtual machine, etc. Click the Manage tab and select Alarm Definitions.
Click the green plus symbol to add a new alarm. Enter a name and description for the alarm, select the type of object to monitor and change the Monitor for option to specific events occurring on this object and click Next.
Click the green plus symbol to add an event. In the Event field enter the EventTypeId to monitor for, that we recorded earlier. The status of the new event is set to Alert by default, click Next.
On the Actions page select how to act upon the alert when the event is generated. This could be by sending an email, automatically running a script, etc.
The alarm has now been created and the configured action will be applied when the event is logged.