Category Archives: VMware

Automating the VSAN HCL with PowerCLI

Recently I was contacted by a customer who needed to be able to update their VSAN Hardware Compatibility List in the VSAN Health Check but was unable to do so via the GUI as their vCenter servers did not have internet access.

This is a common setup as a lot of customers clearly do not want their Server infrastructure having a direct connection to the internet due to strict security requirements. The problem is when the vCenter server needs to update the VSAN HCL database file it requires a connection to the internet to do this. Whats more, this specific customer had several VCs and was getting quite frustrated with the warning that the HCL database had not been updated. Rather than turning this feature off the customer was looking for a way to update the HCL from a computer that had internet access – his desktop.

New in PowerCLI 6.5 (backwards compatible to previous versions) is a cmdlet that will help us achieve this… Update-VSANHCLDatabase, as you can see from the below image this can be run either grabbing the database information directly from the internet or if you add the “FilePath” parameter you can load the database locally.

Continue reading Automating the VSAN HCL with PowerCLI

Getting started with PowerCLI 6.5 and Horizon View

One of the recent enhancement released in PowerCLI 6.5 R1 was the addition of a new Horizon View Module which allows you to manage Horizon View from a remote connection, this is a huge enhancement from the previous PowerShell implementation which fell short by many means.

With the new Horizon View Module you will be able to access 100% of the public API meaning if its available as a feature in the UI then the likelihood is that you will be able to automate it and being able to use these from a scripting host with all the other PowerCLI features, your own workstation or a jump box makes this very convenient.

What do I need?

Lets get started…


Get-Module –ListAvailable VMware*Horizon* | Import-Module

Get-Command –Module Vmware.VimAutomation.HorizonView


Once you have installed PowerCLI 6.5 R1 and launched it you will see that if we import the module and list the commands all we have is 2 cmdlets to work with, well that isn’t much use is it?! or is it?
Continue reading Getting started with PowerCLI 6.5 and Horizon View

Automating the build of your vSphere 6.5 home lab

This year at VMworld SFO and BCN I was involved in organizing a couple of great hackathons with the @VMwareCode guys and William Lam, these were highly successful and I have to say the highlight of both my VMworlds.  The teams were great, the end projects were fantastic and most of all, everyone that attended told me they learned something, this if you ask me was the main objective for the hackathon.

If you attended I do want to extend a huge thanks for joining in, having fun and learning with us.


To put the hacakthon together we needed to build up some environments for people to use, William came up with the idea of using Intel NUCs as these were easily transportable and packed a punch for their size, the equipment we purchased is listed below:

Quantity: 2 Crucial 16GB Single DDR4 2133 MT/s (PC4-17000) SODIMM 260-Pin Memory – CT16G4SFD8213
Quantity: 1 Intel NUC Kit NUC6i3SYH BOXNUC6I3SYH Silver/Black
Quantity: 1 Samsung 850 EVO 500GB 2.5-Inch SATA III Internal SSD (MZ-75E500B/AM) (For Capacity)
Quantity: 1 Samsung SM951 128 GB Internal Solid State Drive MZHPV128HDGM-00000 (For Performance)

For the hackathon we needed to build a lot of these units, whilst we did some parts of it manually William and I recently took the time to complete the automated deployment of these units, in fact the script is not specific to these units, it will work on any ESXi host with 2 disks, one for performance and 1 for capacity.  Of course you can also adjust the script to use more disks if you have them!

Once you have ESXi on a USB insert it into the machine and configure it to boot from the USB, after the ESXi machine is on the network you can alter the configuration settings in the start of the script and run the script in the Deployment Script section of this blog to automate the following:

  • Configure VSAN in a single node configuration (Unsupported)
    • Use the smaller SSD for performance
    • Use the larger SSD for Capacity
  • Configure NTP on the ESXi Host
  • Enable SSH on the ESXi Host for debugging
  • Configure the Syslog settings on the ESXi Host
  • Deploy the VCSA on the ESXi Host
  • Enable VSAN Traffic on the Management Network
  • Create a Datacenter
  • Create a Cluster
  • Create a subscribed content library for William Lams Nested ESXi Library
  • Enable Autostart so the VCSA VM starts when the ESXi machine powers on
  • Enable SSH on the VCSA Server

Continue reading Automating the build of your vSphere 6.5 home lab

VMworld VMware Code Hackathon to hit Barcelona 2016

NUCs.jpgOne of my most memorable and enjoyable times this year at
VMworld USA was the Hackathon, basically 5 teams of developers and scripters, who had mainly never met each other before were formed and took part in a Hackathon organized by myself, William Lam and the VMware Code team.  These dedicated coders gave up free vendor meals and alcohol (OK well maybe we provided both as well) to essentially come code with us on 5 Intel NUC units we had pre-built with vCenter/ESX and VSAN.

The people who were involved ranged from people just learning to coding ninjas and API experts, that’s what I loved, seeing these people learning and working together was truly awesome!

What was involved?

The 5 teams each individually worked on a project which they had come up with and registered before the event, they ended up producing 5 individual projects which were judged and a winning team was selected.

The projects will soon all be available on github or commits to existing projects so the entire VMware community can benefit.

The projects were varied throughout the VMware product range and are listed below:

  • Team 1 – Worked on a project which provided community health check against the vSphere platform (vCheck Enhancements)
  • Team 2 – Worked on Autoscaling Groups for vSphere
  • Team 3 – Worked on writing vSphere DSC resources for Configuration Management
  • Team 4 – Worked on Visualizing Ops: VMware Telemetry with Snap and Grafana
  • Team 5 – Worked on Using Test Driven Development to validate NSX

I know everyone who attended thoroughly enjoyed the event whether they were part of a team or just turned up to spectate, drink, eat and heckle. Continue reading VMworld VMware Code Hackathon to hit Barcelona 2016

Working with maintenance mode in vROPs via PowerCLI

A while back I was contacted by someone who knew that PowerCLI now worked with vRealize Operations (vROPS) and knew it covered the entire API but was unsure how to get to the point where they could achieve what they wanted.

Before I go into what they were doing I highly recommend that if you are interested in learning what is available via VROPs and PowerCLI you check out the following awesome posts by John Dias

And specifically check out this post which tells you the more advanced feature of being able to access the entire API and create your own functions.

So, the story around this script was that this person was heavily using vROPs in their environment to monitor and troubleshoot their VMware infrastructure, they had it highly tuned but also used PowerCLI to automate some maintenance and updates of the infrastructure, the problem was that every time they performed these tasks they would get automated alerts from vROPs to tell them that things were down or not behaving correctly.

This while expected was clearly a pain as we all know that unwanted email from a monitoring system can get tedious and eventually ignored to the detriment of something important being missed.

Continue reading Working with maintenance mode in vROPs via PowerCLI

A Quick Reference of vSphere IDs

How do you identify the components within your virtual environment? You give them names right?! Well to programmatically identify the same components that’s exactly what VMware does but rather than names they give them IDs and guess what, there are a lot of different IDs, so many that people often get mistaken by which ID to use in which circumstances and what they refer to.

After a discussion with one of VMware’s brightest engineers (Thanks Jeff Hu) and a long email thread where he dumped his brains on what these IDs were for, I thought I would blog them and make use of this awesome information.

vCenter IDsSo here goes, here is a list of a number of the different IDs used in the virtual infrastructure and how they are used:

image1. VC Instance UUID (aka serverGuid): This is a GUID that identifies the vCenter server.  This is accessible from the AboutInfo property in the VIM API.  The property name is AboutInfo#instanceUuid.  It’s set at install time and is persisted so the value is durable for a given VC instance.

To access this via PowerCLI you can use the following:

PS C:\> $vcenter = Connect-viserver vcsa-01a.corp.local -User Administrator@vsphere.local -Password VMware1!

PS C:\> $vcenter.InstanceUuid


2. The ESX Host UUID is read by the ESX host from the System Management BIOS (SMBIOS). This UUID is not generated by VMware, it is unique to the hardware and is set in the BIOS by the vendor.

To access this via PowerCLI you can use the following:

(Get-VMHost | Select -first 1).ExtensionData.hardware.systeminfo.uuid

3. VC-VM Instance UUID: This is the vc.uuid property in the VM vmx configuration file and also the instanceUuid property on the VmConfigInfo for a VirtualMachine in the VIM API.  This UUID is used by vCenter to uniquely identify VMs that it is managed.  vCenter assigns this UUID to the VM after it is created.  There are different workflows where a VM may not have a UUID initially or may have a duplicate.  vCenter actively looks over the VM inventory and will automatically patch the VM instance UUID if it sees a duplicate.

The scope of this uniqueness scan is a vCenter instance.  If there are duplicate VC-VM Instance UUIDs, they will not be detected as duplicates unless the VMs are managed by the same vCenter instance.  This value can be changed through the API.

To access this via PowerCLI you can use the following:

PS C:\> (Get-VM | Select -first 1).extensiondata.config.InstanceUUID


4. VM SMBIOS UUID: This is the uuid.bios property in the VM vmx configuration file.  In the VIM API, this is the uuid property on the VmConfigInfo for a VirtualMachine managed object.  This UUID is visible to the guest OS as the SMBIOS UUID.  VMware generally try to avoid changing this UUID since it is often used by applications that manage the guest OS instances.  When the VM is migrated this UUID is maintained.

vCenter does a best effort to try to make sure these UUIDs are unique in an environment.  For operations like clone and deploy that create a new VM, a new UUID is provided to the VM by clearing the uuid.bios from the VM’s vmx file.  If the VM is copied without vCenter’s knowledge, 3rd party tools are advised to do the same thing as vCenter.  A new uuid.bios is generated the next time the VM is powered on.  This UUID is generated by the ESXi server so vCenter does not have to be in the control flow for the uuid.bios to be generated.

To access this via PowerCLI you can use the following:

PS C:\> (Get-VM | Select -first 1).extensiondata.Config.UUID


5. VM Location ID: This identifier is stored in the VM configuration file as the variable uuid.location.  In the VIM API, the name is locationId also on the VmConfigInfo of the VirtualMachine.  This is one other detail that might be relevant to a 3rd party solution that might be moving the VM without vCenter’s knowledge.  This property is used in conjunction with the VM SMBIOS UUID.  This property is a hash of the VM’s configuration file and some UUID of the ESXi. The purpose of this UUID is to detect out-of-band migrations and copies of the VM.  If vSphere (or Workstation/Fusion) detect that the locationId is no longer valid, it will pop up dialog/question/error asking the user why the locationId is no longer valid.  The user is prompted to answer whether the VM was moved or copied.  The purpose is so that vSphere can determine whether it should keep the existing the SMBIOS UUID or generate a new one.

Recall, I mentioned that vCenter is doing a best effort to ensure the SMBIOS UUID is unique.  But when it detects a potential conflict, vCenter will not automatically patch the UUID since this could break 3rd party and VMware products that rely on the guest visible UUID to correlate the VM with other management entities in the environment.

The way 3rd party solutions can best interoperate with vCenter and it’s attempt to preserve a unique SMBIOS UUID is to be aware of these semantics.  If a 3rd party solution or program is moving the VM, it should clear out the uuid.location (ie. ConfigInfo.locationId) property.  On next power on, a new uuid.location will be generated, binding the VM to ESXi host and the file path where it is running.

Despite this however, there is a theoretical and real possibility that there could be duplicate SMBIOS UUIDs.  Because vCenter is deferring to what the user of the system what the the SMBIOS UUID should be, it will not change the UUID automatically if it detects conflicts.  If there SMBIOS UUIDs that are duplicated, it will not fix them.

To access this via PowerCLI you can use the following:

PS C:\> (Get-VM | Select -first 1).extensiondata.config.LocationId


6. VM MoRef: The VM MoRef is a short key used by a vCenter instance to identify the VM.  This is the primary identifier used by the VIM API to refer to the VM.  The other identifiers can generally be used to find the VM, but the VM MoRef is the one that must ultimately be used to get data and issue operations to modify the VM.

In general, the MoRef is the important identifier because that’s what is used in the VC database to associate a VM to its stats, events, and configuration.

In environments where multiple vCenters are used, the MoRef will not necessarily be unique.  As a result, another identifier needs to paired with the VM MoRef or used instead.  In general, vSphere uses a combination of the vCenter instance UUID (ie. the serverGuid) with the MoRef to identify the VM for cross-vCenter scenarios like Linked Mode.

To access this via PowerCLI you can use the following:

PS C:\> (Get-VM | Select -first 1).ExtensionData.Moref.Value


More Information

William Lam also has some awesome posts on IDs which you may find useful, please read these for further related information:


A lot of Information and different IDs I know but hopefully this will help you identify which to use and when so that you can get the most out of your Virtual Infrastructure!

Adding a vGPU For a vSphere 6.0 VM via PowerCLI

I had a conversation with a VMware customer the other day and they were asking if there was a way to automate the addition and removal of a vGPU to a VM dynamically on a requested or scheduled basis, VMGuru has a great post here on what exactly a vGPU is, I highly recommend reading it.

They asked for a PowerCLI command or function to configure the VM graphics card, specifically to assign a vGPU resources to the VM, a desktop user’s VM is configured by default with vSGA (to not tie up  vGPU resources) then the user schedules the vGPU resource for a specific time frame using their end user portal, before the scheduled vGPU reservation time frame the user is logged out and the script would kick in. The script would reconfigure the VM settings and assigns a vGPU profile to it, the equivalent of what is being done in the UI as follows:


Continue reading Adding a vGPU For a vSphere 6.0 VM via PowerCLI

VMware Flings – The inside story

Recently I was asked to participate in a video where I spoke about the recent Onyx For Web Client fling, this was the winner of the Fling contest held in 2015 and produced and released a while back, more information on the fling and how to use it can be found here, and an informational video can be seen at the end of this post.

As part of the fling I was asked some questions on how it was achieved and what flings take to produce at VMware, I have always liked the idea of flings and fully support a number of flings from VMware both internally to the company and externally, as an addition to the video I thought I would also share the answers to the questions I was asked and give you an insight on what it takes to get a fling out and what it means to the development staff at VMware.  Something I would highly recommend in any company to help create and spread innovation throughout the products.

Onyx For the Web Client was certainly close to my heart, being able to give developers and system administrators a record and show feature that allows them to investigate our APIs and learn more is always a good thing.

Find below some Q&A on the fling:

How did you and your team bring the concept from vision to reality?

When someone from the CTO office calls your phone, you answer! But honestly, we already had seen the value and the tremendous following with the old version of Onyx and were aware of the limitations it had, specifically when moving to the web client.  We had already been looking at a web client version of Onyx so when this item won the fling contest we jumped at the chance to be involved.

As a customer I used the original version of Onyx on a weekly basis, the value of being able to automate your infrastructure is huge and if you can find out how VMware does a particular task and convert that to code it doesn’t take much to include it in your custom automation solution and prevent yet another manual task, after all isn’t this the promise of the SDDC J

Being the Product Manager of the PowerCLI team all I needed to do was share the vision with an eager team member, in this case it was Atanas Atanasov, a forward thinking developer in the PowerCLI team, someone who is keen to make an impact and provide the best solution for our customers.  He took some original work that had already been started as part of an intern project and polished it up, added features and ran through the entire development and internal feedback process to produce an awesome fling!

Innovation is hard to manufacture. How did your team at VMware collaborate to innovate in the context of this project?

Innovation in my mind is coming up with a unique way to solve an important customer issue, this is exactly what we did in this case.

When moving towards an automated datacenter, VMware customers need all the help they can get to quickly move from manual tasks to automated tasks and the most popular method of doing this at the moment is PowerCLI, this fling helps our customers understand exactly what happens “under the covers” and replicate this in their scripts.

How does the VMware leadership team help support innovation within the company? How did this affect the development of the Onyx for the Web Client Fling?

The VMware leadership team were fully supportive.  Flings are often worked on in the developers spare time at VMware and I can tell you as the PM for PowerCLI we do not give the developers any spare time!  The VMware leadership team helped me to bring incentives to the engineer, in this case a fully endorsed trip to VMworld where he could share his hard work with the customers that he has helped in producing this very fling.  Atanas and I were able to stand on the Office of the CTO booth talking about the fling and helping customers with automation. It was great to receive their direct feedback and watch their faces when they saw it in action and how much time it would save them.

What’s the reaction been to the Fling since its release?

WOW! The community for PowerCLI and automation was abuzz with the news of this fling, I lost count of the social media comments and blog posts which called this out as an amazing achievement from VMware and a great help to our customers.   When you have a good solution that customers see the value in it is a great day to be a Product Manager at VMware!

Besides this Fling, what’s your favorite Fling?

There are many amazing flings on the flings site, it’s hard to choose just one.  I guess I would need to stay on the automation theme though.

PowerActions is probably my favorite fling, this is kind of the reverse of “Onyx for the web client”, it gives our customers a way to feed their automation back into the web client and perform custom scripted reports and actions on the items in the web client.  Essentially it allows our customers to customize the GUI and gives them a way to perform automated tasks in their day to day console.  Not only this but also share the wealth of expertise that the senior automation engineers have by allowing them to create custom actions for everyone who uses the web client.

Together with “Onyx for the web client” I believe PowerActions is an amazing solution for the automated Software Defined Datacenter.

More Information

Make sure you check out the VMware RADIUS site here for more information on this and watch the video below:

PowerCLI 6.0 R2 – The most advanced version VMware has ever made

imageThis week VMware released a new version of PowerCLI and this release is the most advanced version ever made.  As the Product Manager for PowerCLI I am particularly proud of this release as we not only add core functionality to the vSphere cmdlets allowing access to report, manage and automate even more of the core infrastructure but yet again we introduce a number of new features allowing PowerCLI to reach even further into the SDDC and automate and integrate more products.

I always like to ask people what they want to see from PowerCLI next and for a long time now people have been talking to me about vROPs and telling me their use cases of being able to use the rich dataset and analytics provided by vROPs to make decisions and take further action with PowerCLI, something as simple as monitoring a web server to know when it is under duress and provision many more based on these statics all the way to being able to take action on storage systems by monitoring the workload over time.  The use cases are endless and now achievable by the latest version of PowerCLI.  More on this to come in a future post but lets just say I am excited to see what the awesome PowerCLI community does here.

There is so much to talk about in this release, I wanted to give you an overview in this post and then dive deeper into some of the key features in the future.

What’s New?

More Module Enhancements

The community made it clear that we had to move to modules, and whilst we are still getting there, in this release we made even more module enhancements, both to the core distribution model of PowerCLI cmdlets and also converting more of our code base from snapins to modules. In this version the License snap-in has been converted to a PowerShell module. In the new release the PowerCLI Modules have also been moved to the System PSModulePath allowing all users of a machine to access them once installed.

vROPS Support

As briefly mentioned above, a new module and cmdlets have been added to this release to allow access to vRealize Operations, access to the entire public API is available from the $global:DefaultOMServers variable using the ExtensionData property and full cmdlets have been included for the most used features, this gives us a good mix of fully functional easy to use cmdlets and yet the access for advanced users to be able to access the entire API through the ExtensionData property to create their own functions to expose anything to automate vROPs.  The following cmdlets were added for using with vROPs:

  • Connection: Connect-OMServer , Disconnect-OMServer
  • Alerts: Get-OMAlert, Get-OMAlertDefinition, Get-OMAlertSubType, Get-OMAlertType, Set-OMAlert
  • Recommendations: Get-OMRecommendation
  • Resources: Get-OMResource
  • Statistics: Get-OMStat, Get-OMStatKey
  • User Management: Get-OMUser

Update Manager

PowerCLI for Update Manager has always been available as a separate downloadable installer but it was hard to work with, you needed to work out which version of Update Manager you had installed on the server and install the exact version of PowerCLI cmdlets to work with it, this was obviously a pain when using multiple versions of vCenter or when trying to manage them from one machine.  In this version PowerCLI for vSphere Update Manager is no longer a separate downloadable component or installer and is now included in the core PowerCLI installer, it is selected by default during the PowerCLI install wizard which allows for simpler and quicker deployment and management of VMware products through PowerCLI. Enhancements have also been made to ensure a better backwards compatibility experience of this module and now supports versions of vSphere Update Manager all they back to 5.5.

vCloud Air

In the previous release we introduced PowerCLI for vCloud Air, allowing you to connect to your dedicated resources you have purchased and transfer your automation skillset into the cloud.  In this release you can now also connect to and manage vCloud Air On-Demand (vCA) instances with the –VCA parameter added to the Connect-PIServer and the new Get-PIComputeInstance cmdlet to list all available compute instances. Existing cmdlets for managing vCloud Director and vCloud Air can be used to work with vCloud Air On-Demand where applicable. Additional to these enhancements a new cmdlet has been added to make it easier and enhance the ability to work with OrgVDC Networks called Get-OrgVdcNetwork.

ESXi Host Hardware

This feature was asked for in the PowerCLI Communities, this is just one of the places we monitor to work out what our future releases look like.  New cmdlets have been added to work with ESXi host hardware, these cmdlets give the ability to interrogate your ESXi hosts and provide core system and hardware information.

Two new cmdlets have been added to work with this area:

  • Get-VMHostHardware lists host information
  • Get-VMHostPCIDevice lists all PCI Devices


Over the last number of releases we keep making enhancements to the storage cmdlets, with VSAN, IO Filters and now a number of enhancements have been made to the storage module introducing new cmdlets for working with VMware vSphere® API for Storage Awareness (VASA), NFS 4.1 and updated vSphere API for IO Filtering (VAIO) cmdlets.

The following new additional cmdlets are now available:

  • New VASA Cmdlets : New-VasaProvider, Remove-VasaProvider, Get-VasaProvider and Get-VasaStorageArray
  • New NFS Cmdlets: New-NfsUser, Remove-NfsUser, Get-NfsUser and Set-NfsUser
  • Added VAIO filters Cmdlet: Set-VAIOFilter

A pet peeve of mine and others

In previous versions of PowerCLI when you started the interactive shell it would always start PowerCLI in the directory where we installed the components, as I watched people use PowerCLI I would see them run a CD\ to get back to the root of the C: or they would use it from the install directory and often their commands would line wrap making it slightly harder to read, a small but hugely beneficial change was made in this release, the PowerCLI starting directory has now been changed from the full install path of PowerCLI to the root of the installation drive.

Business as usual

As usual updates have been made for PowerCLI to support the latest versions of the software it works with, in this case Site Recovery Manager (SRM) was updated to 6.1 and additional functionality has been added to discover SRM servers when they are deployed in a “shared recovery model” and support has been added for the vCloud Director 8.0 features which are provided by the backwards compatibility agreement of the VCD API.  All this and many more bug fixes and speed enhancements.

What an awesome release!