WilliamLam.com

How to check when the VSAN Hardware Compatibility List (HCL) is updated?

by // 2 Comments

While catching up on emails from being out on paternity leave, I came across a VSAN HCL feature request that I had filed in early December of last year. I was pleasantly surprise to see that it had been marked resolved. The VSAN Hardware Compatibility List is continuously being updated to include new hardware platforms and components that have been certified by our hardware vendors.

This of course is great news for our customers, but one challenge that I have heard on several occasion is how to keep up with the changes, especially the addition of new components? The VSAN HCL allows you to subscribe and get notification on individual components which is useful to get the latest recommendation. However, in the case of new components being add or even removed, there is no easy solution and most folks resort to manually checking the VSAN HCL by hand.

VSAN itself does include an HCL healthcheck, which you can have it directly pull the latest VSAN HCL JSON from VMware's website, although this may not always be possible for customers without direct or proxy access to the internet. This means for customers who may have dark sites, they must periodically download the latest VSAN HCL JSON and distribute that throughout their vCenter Server, where as a more ideal solution is to only push the update when a new JSON has been provided by VMware.

My feature request was quite simple, it asks for a method in which customers can easily subscribe and get notified of when the VSAN HCL database has been updated. This has been delivered as a tiny RSS feed service.

[Read more...]

Translating vSAN VM Object IDs (UUID to VM and VM to UUID)

by // 2 Comments

I was working on one of my vSAN Clusters a few weeks back and I had noticed a bunch of vSAN Objects being listed under the "Other" category within the vSAN Virtual Objects Health view as shown in the screenshot below.


I could not figure out what files or VMs these vSAN objects were actually associated to and it was especially strange since all VMs that were deployed on my vSAN Cluster were already properly showing up under this view and I could not account for these "Other" vSAN Objects. I had reached out to a few folks to see if anyone knew how to identify these objects and the only suggestion I had received back was try to run this python vSAN Health Status script located on one of the ESXi hosts participating in the vSAN Cluster to see if it provided what I needed.

The script is located at /usr/lib/vmware/vsan/bin/vsan-health-status.pyc and you run it like the following:

python /usr/lib/vmware/vsan/bin/vsan-health-status.pyc > /tmp/output

The above command just runs the script and stores its output (which is quite extensive) to /tmp/output. Once the script finishes, you can then open up the file using vi and search for the specific vSAN Object UUID in question. I was able to eventually identify what these vSAN Object UUIDs were mapped to (more on this later), but the overall experience was not ideal and it required SSH access to ESXi host which most customers disable by default. In addition, the process was pretty manual and tedious if you wanted to check multiple vSAN Object UUIDs.

So what did I do, well I looked for a better way of course! It turns out the output produced by vsan-health-status.pyc is actually all available using the vSAN Management API. Not only can you obtain this information programmatically and remotely but you can also retrieve this information by simply going to vCenter Server rather than having to directly connect to an ESXI host which was huge negative for me regarding the previous solution.

[Read more...]

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.