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.

Quick Tip - Locating SRM Placeholder VMs using the vSphere API

by // 5 Comments

I had received a question the other day from a reader where they were trying to distinguish between the running VM and its placeholder VM due to their use of VMware Site Recovery Manager (SRM). Since the VM name is exactly the same in both vCenter Servers, it was not clear how to identify between the two. As mentioned in my reply to the reader, there are a couple of ways. You could use the SRM API in-conjunction with the vSphere API (in his case, he was using PowerCLI) to be able to check whether the VM in question was the placeholder VM or not.

Another option is to simply use the vSphere API and querying for the managedBy property which is populated when SRM and/or other solutions are associated with managing a set of VMs. In the case of SRM, you will see an extensionKey with value of "com.vmware.vcDR" and type with value of "placeholderVm" which tells you that the VM is an SRM Placeholder VM, pretty easy, right!? 🙂

Since I did not have an SRM environment handy, the next best thing was to check out VMware Hands-On-Lab environment which anyone can access for free. Lab HOL-1705-SDC-1 was exactly what I needed and here is a quick screenshot of the vSphere MOB showing you what the managedBy property looks like in the vSphere API.

To demonstrate the use of this vSphere API, I wrote a quick PowerCLI function called PlaceholderVMs.ps1 and below is an example of running the Get-PlaceholderVM command:

Uniquely identifying VMs in vSphere Part 3: Enhanced Linked Mode & Cross VC-vMotion

by // 7 Comments

Back in 2012, I had published two articles which provides details and guidance on how to uniquely identify a Virtual Machine for both a vSphere and/or vCloud Director environment. The primary use case for this information was for customers or partners who have developed their own provisioning solution which requires them to track their VM assets throughout their lifecycle, usually in some sort of configuration management database (CMDB).

Although these articles are almost 5 years old, the content is still very relevant today and I still continue to reference them both with customers, partners and even some of our internal R&D folks. Most recently, I had a question about whether the guidance in these article were still applicable or whether they would be impacted by some of the new VMware technologies and capabilities that had been introduced since writing those articles such as Enhanced Linked Mode (ELM) and Cross vCenter vMotion (xVC-vMotion).

[Read more...]