WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Search Results for: vmc

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 // Security, vSphere Tags // alarm, audit, PowerCLI, reconfigvm, syslog, VmReconfiguredEvent, vSphere API

How to audit VM reconfigurations and see what exactly changed?

08.13.2015 by William Lam // 27 Comments

A question that I almost always see come up on a regular basis is around the topic of auditing or understanding what configuration changes were made to a given Virtual Machine. Today, the process of identifying this information is actually quite difficult at least without resorting to a custom built solution which allows you to compare the configuration changes over time. This is definitely an area that VMware is investing heavily in and although I can not go into specific details, believe me when I say they are taking this very seriously both from a data completeness standpoint as well as simplifying the user experience.

Having said that, what options exists for customers today?

  1. Custom Solution - A system that could periodically snapshot your VM configurations into some type of data warehouse or CMDB platform. There are many challenges here but the biggest one is efficiently capturing the changes and ensuring you do not impact the overall performance of your vCenter Server, especially with larger inventories.
  2. vRealize Air Compliance - This is a new VMware SaaS offering which provides both compliance and remediation for your VM Configurations. I had a chance to preview this awhile back and I have to say it is a pretty slick solution. You can easily step back in time to see exactly what has changed for a given set of VMs, very intuitive UI. You can also add additional configurations to monitor and be alerted on when you are out of compliance. Definitely something worth checking out, especially for customers who must go through regular audit reviews.
  3. vCenter Configuration Manager - I have not personally used this tool before, but I have been told it would also be possible to detect configuration changes for your VMs.
  4. Enabling "Trivia" Logging in vCenter Server - Though this is an option, it is not one that I recommend for variety of reasons. The "Trivia" logging mode is very verbose and will generate huge amounts of data which will causes your logs to quickly rotate out if you are not forwarding to a remote syslog server. There's also additional overhead cost for this type of logging and more importantly, it may not capture all of the required data. This is an approach that some customers have tried but is not really a practical solution.

This topic has always been interesting to me and with several recent inquiries from the field, it got me thinking about this area again. While working on a completely different project, I ended up on Luc Dekens awesome blog and came across his Events Part 3: Auditing VM Device Changes article. If you take a look at the article, you will see that Luc shows you how you can easily audit changes to a VM's devices (e.g. Virtual Disk, CD-ROM, etc). What Luc demonstrated in his script is just a specific type of configuration, but the point is that this type of information has always been available, just not easily consumable.

The secret is to key off of the VmReconfiguredEvent which includes a configSpec property that captures the exact set of configuration changes for a given VM. Below is an example of the configSpec dump of one of these events. We can clearly see that this VM had its vCPUs modified to 4 and its vMEM modified to 20GB.

what-changed-when-vm-is-reconfigured-2
With this information, we can now easily query the configuration changes for a given VM by looking through its past events. Leveraging the awesome work that Lud has already done with his script, I slightly enhanced it to cover more than just device changes but overall VM configuration changes. With that, here is a PowerCLI script/function that I created called Get-VMConfigChanges.ps1

Note: The amount of historical events that you will be able to search through will purely depend on your Center Server DB's retention period of Tasks/Events. For VMs which have been deleted, you will not be able to retrieve any events as they must be associated with an object in the database.

Below is an example of how to use this function which accepts a VM object and the number of hours (default to 8) to search through the VM's events:

$vcserver = "192.168.1.150"
$vcusername = "*protected email*"
$vcpassword = "VMware1!"

Connect-VIServer -Server $vcserver -User $vcusername -Password $vcpassword

$vm = Get-VM "Test-VM"

Get-VMConfigChanges -vm $vm -hours 12

Disconnect-VIServer -Server $vcserver -Confirm:$false

From the output below, we can clearly see the following configuration changes have been applied:

  1. Change vCPU to 2
  2. Change vMEM to 4GB
  3. Change vMEM to 5GB and Edited Virtual Disk (you can of course get further details by dumping more information)

what-changed-when-vm-is-reconfigured-1
Although this solution is not as clean as the vRealize Air Compliance offering, it does allow anyone to quickly pull out the relevant configuration changes for a given VM along with the user and time the configurations was performed. Hopefully this goes to show how powerful the vSphere Platform APIs really are and it is definitely worth while in learning how they work.

Categories // Security, vSphere Tags // audit, PowerCLI, reconfigvm, vm configuration, VmReconfiguredEvent, vSphere API

vCenter Server 6.0 Tidbits Part 1: What install & deployment parameters did I use?

04.06.2015 by William Lam // 6 Comments

This is the first part in a new blog series that I will be working on in which I will be sharing some simple tips and tricks that I learned along the way while working with vCenter Server 6.0, these especially came in handy during the early development of vSphere 6.0. These tidbits will include information covering both the vCenter Server for Windows (VCS) as well as the vCenter Server Appliance (VCSA).

When installing VCS or deploying the VCSA, you are prompted to fill out a variety of inputs based on the deployment type, SSO Domain, database information, etc. These "install parameters" are then fed into the configuration of either your vCenter Server (Embedded) or separated out with vCenter Server Management Node and Platform Services Controller Node.

Screen Shot 2015-04-02 at 1.15.54 PM
After you successfully deployed your vCenter Server and say a couple of weeks has passed and you are now wondering what install parameters you used either for auditing, informational purposes or more likely you may need to know one of these parameters for adding additional instances say for Enhanced Linked Mode, how might you go and retrieve this information?

Luckily, VMware has made finding this information extremely easy by providing a tiny little utility called "install-parameter" and here are the locations for both platforms:

Windows:

"C:\Program Files\VMware\vCenter Server\bin\install-parameter.bat"

VCSA:

/bin/install-parameter

The utility accepts the name of a well defined set of installation parameters, an example would be "vmdir.domain-name" which specifies the name of the SSO Domain that you had configured:

vc-deployed-defaults-0
You can see the complete list of available installation parameters under the following paths in the two platforms:

Windows:

C:\ProgramData\VMware\vCenterServer\cfg\install-defaults

VCSA:

/etc/vmware/install-defaults

For your convenience, I have also listed all the installation parameters in the table at the very bottom of this post.

In addition to these installation parameters, there are two additional ones that I would like to mention which are not part of this list.

Database Type

The information is stored in a file called db.type with possible values of: embedded, oracle and mssql and here are the paths for the two platforms:

Windows:

C:\ProgramData\VMware\vCenterServer\cfg\db.type

VCSA:

/etc/vmware/db.type

vc-deployed-defaults-2
The possible values for this files is: embedded, oracle and mssql

Deployment Type

The information is stored in a file called deployment.node.type with possible values of: embedded, management and here are the paths for the two platforms:

Windows:

C:\ProgramData\VMware\vCenterServer\cfg\deployment.node.type

VCSA:

/etc/vmware/deployment.node.type

vc-deployed-defaults-1
For those with a critical eye, you might have noticed there is one installation parameter that is not available in any of these files and that would be the SSO Domain Site Name. This property is not really important (outside of troubleshooting) unless you need to add additional Platform Services Controller and replicate with an additional one or adding additional vCenter Servers for enabling Enhanced Linked Mode support. This property is one of the required parameters when performing a scripted install but is not needed if performing the deployment using the guided install method. In the next blog post, I will show you how you can retrieve this property.

vCenter Server 6.0 Installation Parameter

autodeploy.ext.managementport
autodeploy.ext.serviceport
cis-license.int.http
cm.int.cmhttp
cm.url
cm.url.path
db.dsn
db.instance
db.presetupdone
db.provider
db.servername
db.serverport
db.user
eam.int.http
invsvc.int.http
mbcs.int.http
netdumper.ext.serviceport
netdumper.int.webport
perfcharts.int.https
rhttpproxy.cert
rhttpproxy.conf.path
rhttpproxy.ext.port1
rhttpproxy.ext.port2
sca.hostid
sca.int.scahttp
sps.int.pbmhttp
sps.int.pbmhttps
sps.int.smshttp
sps.int.smshttps
sps.int.spshttp
sps.int.spshttps
sshd.ext.port1
syslog.ext.port
syslog.ext.tls
syslog.int.http
syslog.int.port
system.hostname
system.hostname.type
system.urlhostname
system.vm0.hostname
vapi.int.endpoint-http
vapi.int.jmx-port
vc.conf.path
vc.home.path
vc.instance.cfg.path
vmafd.ext.port1
vmca.cert.dir
vmca.ext.port1
vmdir.admin-dn
vmdir.domain-dn
vmdir.domain-name
vmdir.ext.port1
vmdir.ext.port2
vmdir.ldap-port
vmdir.ldu-guid
vmdir.site-guid
vmdir.username
vmkdc.ext.port1
vmkdc.ext.port2
vmkdc.ext.port3
vpostgres.int.server_port
vpxd.ext.port1
vpxd.ext.port2
vpxd.int.sdk-port
vpxd.int.sdk-tunnel-port
vsan-observer.ext.port1
vsm.int.http
vsm.int.https
vsphere-client.ext.port1
workflow.int.jmx-port
workflow.int.service-port
workflow.int.vapi-port

  • vCenter Server 6.0 Tidbits Part 1: What install & deployment parameters did I use?
  • vCenter Server 6.0 Tidbits Part 2: What is my SSO Domain Name & Site Name?
  • vCenter Server 6.0 Tidbits Part 3: Finding all deployed Platform Services Controller
  • vCenter Server 6.0 Tidbits Part 4: Finding all deployed vCenter Servers
  • vCenter Server 6.0 Tidbits Part 5: New method of patching the VCSA
  • vCenter Server 6.0 Tidbits Part 6: Customizing VCSA’s DCUI
  • vCenter Server 6.0 Tidbits Part 7: Connecting to SSO/PSC using JExplorer
  • vCenter Server 6.0 Tidbits Part 8: Useful ldapsearch queries for vmdird
  • vCenter Server 6.0 Tidbits Part 9: Creating & managing SSO users using dir-cli
  • vCenter Server 6.0 Tidbits Part 10: Automating SSO Admin configurations
  • vCenter Server 6.0 Tidbits Part 11: Automate SSO Admin password change
  • vCenter Server 6.0 Tidbits Part 12: New methods of downloading Support Bundles for VCSA / PSC

Categories // Uncategorized Tags // db.type, deployment.node.type, install-parameter, vCenter Server, vcenter server appliance, VCSA, vcva, vSphere 6.0

  • « Previous Page
  • 1
  • …
  • 47
  • 48
  • 49
  • 50
  • 51
  • …
  • 55
  • 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
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Configuring OIDC with PKCE in Keycloak for VCF Private AI Services 08/26/2026
  • VCF 9.1 - Understanding VCF Converge & Import Scenarios for vCenter Server Without NSX 08/24/2026
  • VCF 9.1 - Configuring Harbor to use VCF Identity Broker (IDB) for External Identity Federation 08/19/2026
  • Quick Tip: The Fastest Way to Clear Partitions for ESX Reinstallation 08/15/2026
  • Quick Tip: Reducing High CPU Utilization in VCF Automation (VCFA) on AMD Zen4/Zen5 CPUs 08/12/2026
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 © 2026

Loading Comments...