WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

How to automatically log all VM configuration changes using a vCenter Server Alarm?

08.18.2015 by William Lam // 9 Comments

If you followed my previous blog post on How to audit VM reconfigurations and see what exactly changed, you may have concluded that historical VM configuration events may potentially be unavailable by the time you need to perform an audit. The reason for this is that the VM Events tables may have rotated out depending on the retention policy of your vCenter Server Database. This is where we can take advantage of the powerful vCenter Server Alarm feature which would allows us to capture every single VM reconfiguration and store this information outside of the vCenter Server. This not only allows you to reduce the amount of data stored in the vCenter Server Database but it also allows you to efficiently archive this data into a data warehouse or Big Data platform that provides more advanced analytics and reporting capabilities.

Building on top of our previous script, I have created a slightly modified version called Get-VMConfigChangesFromAlarm.ps1. The main difference is instead of passing in a VM object to look for past configuration changes, the script can now pull in information from a triggered VmReconfigureEvent and log the specific changes associated with that VM reconfiguration. The way in which it does this is by querying the following two environmental variables which are set when the vCenter Server alarm is triggered and below is an example of their values:

Alarm Environmental Variable Value
VMWARE_ALARM_TRIGGERINGSUMMARY Event: VM reconfigured (9322)
VMWARE_ALARM_TARGET_ID vm-125

In the first variable, what we care about is the eventId which is associated with the VM reconfiguration. What I have found is you have to take this ID and subtract 1 to get the event which actually contains the reconfiguration information that we want. The second variable provides us with the MoRef ID of the VM that was configured. Using these two pieces of information, we can then perform an event lookup to pull out the configuration changes that were made to that particular VM.

Here are the steps for creating the vCenter Server Alarm:

Step 1 - Ensure that the latest PowerCLI 6.0 Release 1 is installed on your vCenter Server. I will assume that this is how you wish to execute the PowerCLI script. If not, other options can include sending an SNMP trap to vRealize Orchestrator and have it perform the execution of the script.

Step 2 - Create a new Alarm and fill in the general settings as shown in the screenshots below.

automatically-log-vm-reconfiguration-changes-0
Step 3 - Add the "VM reconfigured" trigger with the status set to "Unset", this will ensure you do not have a notification icon when the alarm is activated.

automatically-log-vm-reconfiguration-changes-1
Step 4 - Select "Run a command" as the action and then paste the full path to where a "wrapper.bat" script will be located in the vCenter Server.

automatically-log-vm-reconfiguration-changes-2
Step 5 - Create the "wrapper.bat" script on the vCenter Server system with the following (adjust the paths to fit your environment):

C:\Windows\System32\cmd.exe /c powershell.exe -noninteractive -noprofile -file C:\Users\primp\Desktop\Get-VMConfigChangesFromAlarm.ps1 >> C:\Users\primp\Desktop\alarm.log

The following snippet will execute the PowerCLI script and any console output will be re-directed to the alarm.log file (which can be helpful in troubleshooting errors in the script itself).

Step 6 - Download the Get-VMConfigChangesFromAlarm.ps1 script and place it on the vCenter Server system and ensure it aligns with the path of the wrapper.bat script. You will also need to edit the script to update the vCenter Server credentials as well as the log file in which the VM configurations will be stored. Currently it will just append to a file called alarm.txt.

If everything was configured successfully, you can now test the alarm by simply editing one of your VMs. If you click under Monitor->Events for the VM, you should see the alarm being triggered and that the script was executed.

automatically-log-vm-reconfiguration-changes-3
If we take a look at our alarm.txt file, we should hopefully see the VM reconfiguration details logged like the following:

ChangeVersion : 2015-08-13T21:10:58.248345Z
DeviceChange : {VMware.Vim.VirtualDeviceConfigSpec}
Files : VMware.Vim.VirtualMachineFileInfo
MemoryMB : 8192
NumCPUs : 2
VMName : Test-VM
Start : 8/13/2015 9:11:17 PM
End : 8/13/2015 9:11:19 PM
State : success
User : VGHETTO.LOCAL\Administrator
Device : VirtualDisk
Operation : edit

Logging the output to a file is just one way of storing this data. I am sure some of you may want to modify the script to forward to a remote syslog collector like vRealize Log Insight for example or directly storing it into a Big Data platform. I will leave that as an exercise for my readers but hopefully this give you idea on how you can automatically archive all VM reconfigurations along with the what, when and who details for auditing and/or reporting purposes in the future.

Lastly, I wanted to give a big thanks to Jonathan Medd who helped me with a problem I was running into when trying to get a PowerCLI script to execute when using a vCenter Server Alarm. It turned out that I had the vCenter Server service configure to run as a local admin and switching it over to a Domain Account resolved my problem.

Categories // Automation, Security, vSphere Tags // alarm, audit, PowerCLI, reconfigvm, syslog, VmReconfiguredEvent, vSphere API

New VOBs for creating vCenter Server alarms in vSphere 6.0

03.02.2015 by William Lam // Leave a Comment

Here are some new VOBs in vSphere 6.0 that I recently came across which can be useful on getting notified on specific events such failed login attempts in ESXi or detecting a device has gone offline in VSAN as some examples. These VOBs can be used to create vCenter Server alarms to take various actions such as a simple UI notification in the vSphere Web/C# Client to sending an email or SNMP trap regarding the event. For more information on how create vCenter Server alarms using VOBs, please take a look at these two articles here and here which also includes a comprehensive list of past vSphere VOBs in vSphere 5.5 which are still applicable in vSphere 6.0.

General vSphere 6.0 VOBs

VOB ID VOB Description
esx.audit.account.locked Remote access for an ESXi local user account has been locked temporarilly due to multiple failed login attempts.
esx.audit.account.loginfailures Multiple remote login failures detected for an ESXi local user account.
esx.audit.esxcli.host.restart Rebooting host through esxcli
esx.audit.lockdownmode.exceptions.changed List of lockdown exception users has been changed.
esx.problem.coredump.copyspace The free space available in default coredump copy location is insufficient to copy new coredumps.
esx.problem.coredump.extraction.failed.nospace The given partition has insufficient amount of free space to extract the coredump.
esx.problem.dhclient.lease.offered.error No expiry time on offered DHCP lease.
esx.problem.pageretire.selectedbutnotretired.high Number of host physical memory pages that have been selected for retirement but could not yet be retired is high.
esx.problem.swap.systemSwap.isPDL.cannot.remove System swap at path {1} was affected by the PDL of its datastore and was removed. System swap has been reconfigured.
esx.problem.swap.systemSwap.isPDL.removed.reconfig.failure System swap at path {1} was affected by the PDL of its datastore. It was removed but the subsequent reconfiguration failed.
esx.problem.vmfs.ats.incompatibility.detected Multi-extent ATS-only VMFS Volume unable to use ATS
esx.problem.vmfs.lockmode.inconsistency.detected Inconsistent VMFS lockmode detected.
esx.problem.vmfs.spanned.lockmode.inconsistency.detected Inconsistent VMFS lockmode detected on spanned volume.
esx.problem.vmfs.spanstate.incompatibility.detected Incompatible VMFS span state detected.
esx.vFlash.VFlashResourceCapacityExtendedEvent vFlash resource capacity is extended
vprob.vmfs.heartbeat.corruptondisk VMFS Heartbeat Corruption Detected

VSAN 6.0 VOBs

VOB ID VOB Description
esx.audit.vsan.net.vnic.added Virtual SAN virtual NIC has been added.
esx.audit.vsan.net.vnic.deleted Virtual SAN network configuration has been removed.
esx.problem.vob.vsan.dom.lsefixed Virtual SAN detected and fixed a medium error on disk.
esx.problem.vob.vsan.dom.nospaceduringresync Resync encountered no space error
esx.problem.vob.vsan.lsom.disklimit2 Failed to add disk to disk group.
esx.problem.vsan.dom.init.failed.status Virtual SAN Distributed Object Manager failed to initialize
vprob.vob.vsan.pdl.offline Virtual SAN device has gone offline.

Categories // ESXi, VSAN, vSphere 6.0 Tags // alarm, vob, VSAN, vSphere 6.0

Detecting duplicate VM MAC Address using vCenter Server Alarm

02.25.2015 by William Lam // 6 Comments

Having a duplicate VM MAC Address in your environment can lead to an extremely painful day of troubleshooting and it can also be tough to prevent depending on how and where you provision your VMs.

There are two cases that I can think of where a duplicate MAC Address can potentially occur:

  1. You manually assign a static MAC Address versus using dynamic assignment (includes VM import) and it conflicts with an already assigned MAC Address
  2. You migrate a VM from one vCenter Server to another and the destination vCenter Server has already assigned the MAC Address of the migrated VM

In both of these scenarios, when a duplicate MAC Address occurs, time is of the essence to quickly pin-point the source of the duplicated entry and quickly resolving the conflict. What would be nice is to be able to automatically detect that a MAC Address conflict has occurred and provide the necessary information of the offending VMs.

UPDATE (4/22) - Thanks to Petr, it turns out there is another MAC Address conflict event which I did not know about specifically for detecting duplicate entries for manually assigned MAC Addresses called "VM static MAC conflict". I definitely recommend creating an alarm for both Events for the vCenter Alarm.

While performing some research in my lab environment the other day, I accidentally stumbled onto this little tidbit in vCenter Server. It turns out there is an out of the box event called "VM Mac conflict" which can be triggered using a vCenter Server alarm when a duplicated MAC Address is detected for a VM. I was actually surprised that this was not one of the pre-created default alarms in vCenter Server as I can see this being extremely useful to have out of the box. In any case, it is simple enough to create a new vCenter Server Alarm and in the example below I called it "Dupe VM Mac Address".

duplicate-mac-address-alarm-0
To test our new alarm, I created a new VM called "VM1" which has been configured with static MAC Address that matches "VM2". Once the VM has been created, we can see that the alarm is immediately triggered and by clicking into the alarm details, it provides the details of the MAC Address and the offending VMs.

duplicate-mac-address-alarm-1
In my opinion this is an alarm that everyone should create in their environment to ensure that if this problem ever occurs, you can quickly get notified and resolve the problem. I have also reported this internally and asked if we can have this alarm created by default, so hopefully this will not be necessary in the near future 🙂

Categories // vSphere, vSphere 5.5, vSphere Web Client Tags // alarm, mac address, vSphere, vSphere 5.1, vSphere 5.5

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • …
  • 7
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...