WilliamLam.com

Reporting vSAN Object distribution across vSAN Disk Groups using PowerCLI

by // Leave a Comment

Several weeks back, I was cleaning up my scratch space, where I store all my random code snippets for various questions which I receive on a regular basis and I came across a nifty little script that I had put together for a particular customer request. I had completely forgotten about it and I thought it could come in handy for some folks who might be curious in how their current vSAN Objects are currently being distributed across all vSAN Disk Groups within a vSAN Cluster.

RVC already provides a nice command called vsan.check_limits which gives you a break down of the number of components across all disks within a vSAN Cluster as shown in the screenshot below.


However, in the case of this particular customer, they wanted the break down on a per Disk Group level rather than individual disks.

Luckily, all of this information is already exposed using the vSAN Management APIs, you simply just need to aggregate it one level up. With that, I created a PowerCLI script called VSANObjectDistribution.ps1 which allows you to provide the name of a vSAN Cluster and it will automatically provide you with both the number of components distributed across the different vSAN Disk Groups as well as the amount of storage consumed by these components.

Here is a screenshot for a 3-Node vSAN Cluster where each ESXi host contains two vSAN Disk Groups:


Since there is no actual number for a vSAN Disk Group, by default, I output the Canonical Disk Name of the "Cache" device for the given vSAN Disk Group so you can map it back.

If you prefer to see the vSAN UUID for the "Cache" device instead, you can simply set the -ShowvSANID parameter to true as shown in the screenshot below.


To correlate back the specific vSAN Disk Group, you simply select a particular vSAN Disk Group for the ESXi host you are interested in. At the bottom, add "vSAN UUID" column highlighted in orange and you can then compare either that ID or Canonical Disk Name highlighted in blue.

Automating vRealize stack based on VVD using new vRealize Suite Lifecycle Management

by // 1 Comment

Our Cloud Management Business Unit (CMBU) at VMware just GA'ed the highly anticipated vRealize Suite Lifecycle Management or vRSLCM for short. As the name suggests, this new solution provides customers a simple and consistent mechanism for managing the entire lifecycle management (Day 0 to Day N) for all VMware vRealize Products including but not limited to Install, Upgrade, Configuration Management, Drift Remediation and Health Monitoring. vRSLCM is delivered as a Virtual Appliance which can be used in either a greenfield and/or existing brownfield environment. You can also manage multiple environments that consists of different vRealize products that have been deployed giving customers 100% visibility into all their different vRealize environments using a single interface. For more information, be sure to check out this blog post here.


One specific feature that I think is worth calling out and not because our team was involved with it is the ability to deploy what vRSLCM calls "Solutions". These Solutions not only correspond to the specific vRealize products being deployed but they also align to the three VMware Validated Design 4.1 Use Cases: IT Automating IT, Micro-Segmentation and Intelligent Operations as shown in the screenshot below.


This means for customers who wish to deploy the vRealize stack based on the VMware Validated Designs can now easily do so by simply selecting one of these solutions and providing their environment specific information such as DNS, NTP, etc. and vRSLCM will deploy and configure the vRealize products as prescribed in the VVD. Customers no longer have to manually read through pages and pages of documentation to get the desired outcome. [Read more...]

PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

by // 10 Comments

I can still remember when I was a VI Admin and how annoying it was to try to correlate the build numbers for my ESX(i) hosts and vCenter Servers that I have deployed with the versions listed on VMware's website. This especially gets challenging when there are multiple patch releases (a, b, c or 01, 02, 03) in between major releases (5.5, 6.0, 6.0u1, 6.0u2, 6.5, etc.). Historically, most customers including myself would retrieve the respective build numbers and then manually comparing them to either the release notes and/or download website which was very tedious.

Although VMware has exposed the version number within our vSphere products since day 1 which can also be retrieved programmatically using the vSphere API (here), it unfortunately does not provide more details than simply the major/minor version (e.g. 5,5, 6.0, 6.5, etc) of the software. Recently, VMware had released a series of VMware KBs which provides a mapping between the build numbers for vCenter Server, ESXi and vSAN to their respective versions which can be found in the links below:

These are definitely a great set of resources that I know many customers including myself have been using since its release. Having said that, the process today is still pretty manual since you need to manually retrieve the build numbers for either a VC, ESXi or vSAN Host (can be automated using vSphere APIs) and then comparing that to the KBs to get the correct versions. How cool would it be if you could *easily* just point to YOUR environment and retrieve the version information for either a vCenter Server (Windows or VCSA), ESXi host(s) or vSAN host(s) without needing to manually perform this lookup each time? Well, I have just done that! I have taken all three KBs and converted that information into a simple PowerCLI script called VCESXivSANBuildVersion.ps1 leveraging our vSphere API and it provides three functions:

  • Get-VCVersion - Retrieves the vCenter Server version given a VC connection
  • Get-ESXiVersion - Retrieves the ESXi version for all hosts given a vSphere Cluster
  • Get-VSANVersion - Retrieves the vSAN version for all hosts given a vSAN Cluster

Here is an example output using the first two functions:


For the vCenter Server version output, you will notice that I am also including the OS platform of your vCenter Server, so you can distinguish between a Windows vCenter Server and a vCenter Server Appliance (VCSA) which can be useful to see if you have been #migrate2vcsa ;). For the ESXi version output, you will notice the "OriginalInstallDate" value, this is actually new API property that was introduced in vSphere 6.5 and it provides you with the original installation date of your ESXi host (more details can be found here) which is pretty neat.

Here is an example output using last function:


If you wanted to take this a step further, you could even take this output and dynamically update the vSphere UI using either Custom Attributes or vSphere Tags so you know what version the software is at any given moment. Its easy enough to set this up as a scheduled task that could run periodically so you always have the latest information provided in the vSphere UIs.

Although this is a significant improvement over the existing manual methods, I think most of you will agree that it would be ideal if this information was natively available within the product which means BOTH UI and APIs. I think we all appreciate versioning of software is not always easy and it can change from release to release for a variety of reasons, most of which may not be technical. If the vSphere platform could dynamically pull this information in either real time and/or through an offline mechanism and provide this association by default, it would greatly improve the experience when needing to troubleshoot or perform maintenance of the vSphere platform. If this is something you would like to see, please leave a comment below providing your feedback. I know I have already pinged our PMs about this and I am sure they would love to hear form you as well!

Additional Information:

Note1: Update levels can be found using the vSphere API, take a look at this article here for more details.

Note2: As of ESXi 6.5 Update 1, the Update levels are also included by default in the Embedded Host Client as shown in the screenshot below:

Note3: As of vSAN 6.2, the vSAN Management API already includes vSAN version information that can be queried. Take a look at this script here which exercises this new API. For example above, I decided to not use this new API since customers may be running older releases of vSAN which is not covered by the vSAN Mgmt API.

Note4: VMware has also published simliar build to version mapping for other VMware products which can find the complete list here.