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:
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.
Earlier this year, I had put together a Python script using the vSAN Management API to help customers easily identify Virtual Machines which have Thick VM swap while running on vSAN. You can find the full details in Duncan's blog post here. The reason I had chosen Python over something like PowerCLI, which I frequently use now, is that I had found a bug within the Storage PowerCLI module which prevented me from accessing the required vSAN Management API.
With the release of PowerCLI 6.5.4 today, this issue has now been resolved and I have created the equivalent PowerCLI script called VSANVMThickSwap.ps1which includes a function called Get-VSANVMThickSwap to retrieve the exact same information as the Python script.
To use the function, you simply pass in the name of a vSAN Cluster as shown in the screenshot below and the script will return all powered on VMs that have been configured with Thick VM Swap.
When logging into the vCenter Server using either the vSphere Web (Flex) or H5 Client, one of the validation checks that is automatically performed by the server is to check the current users password expiry. If you account expiry is less than the current password expiry configuration, then you will see the yellow notification pop up at the top stating:
Password will expire in X days
This is definitely a helpful feature to have automatically built into the vSphere UI and the default expiry actually depends on the type of user logging into the system. This last part is sometimes confusing as folks mix up the default Single Sign-On User Expiry with the Active Directory user expiry which is completely different.
If you are logging in as an Active Directory user, the password expiry notification by default is 30 days but the actual password expiry will obviously depend on your Active Directory system. If you want to change the expiry notification in case your expiry is not 30 days or you wish to notify sooner or later, this is actually controlled by the vSphere Web and H5 Client.
As the adoption of vSphere Content Library continues to grow, I am seeing more questions from our field and customers around content distribution. In case you did not know, vSphere Content Library (CL as I will be refering to it going forward) has its own built-in native replication mechanism which allows customers to easily publish and subscribe to libraries from either within a single vCenter Server instance or even between two completely different vCenter Servers (regardless of deployment topology and/or SSO Domain configurations).
Content distribution or replication is handled by CL which is a service within the vCenter Server. If content is being replicated from within a single vCenter Server and the ESXi hosts can communicate with each other, then direct host to host transfer is used, also referred to as Network File Copy (NFC), rather than going through vCenter Server. When content is transfered between two vCenter Servers, then the data travels through vCenter Server using standard HTTPS (443) by default. In the latter scenario, if you have configured Enhanced Linked Mode for your vCenter Servers, then NFC will be used unless ESXi hosts can not communicate with each other than, it will automatically fall back to the default HTTPS which is pretty cool.
One thing that may not be very well known is that customers actually have a choice in how their CL content is replicated. In addition to native replication which currently does not support incremental/detla updates, meaning all file transfers are full copies, CL can also support external replication. In fact, many customers today already have existing methods for efficiently replicating large amounts of data across multiple datacenters whether that is replication built into their storage arrays, network appliances or some other means. For these customers, you can still benefit from CL while continue to take advantage of your existing methods of replication.
At VMworld this year, I had received several questions from customers asking whether it was possible to move an ESXi host configured using LACP/LAG from one vCenter Server to another, similar to the workflows outlined here or here. Not having spent much time with LACP/LAG, I reached out to a fellow colleague who I knew would know the answer, Anothony Burke, who you may know as one of the co-creators of the popular Automation tool PowerNSX.
Anthony not only verified that there was indeed a workflow for this scenario, but he was also kind enough to test and verify this in his lab. Below is the procedure that he had shared with me and I merely "prettified" the graphics he initially drafted up 🙂
At a high level, the workflow is similar to the ones shared earlier. The main difference is that for an LACP/LAG-based configuration, you must convert from VDS to VSS and then disconnect from one vCenter Server to the other, you can not simply disconnect and "swing" the ESXi host like you could for non-LACP/LAG configuration or you will run into issues. Once you have re-added the ESXi host to the new vCenter Server, you simply reverse the procedure from VSS to VDS and re-create your LACP/LAG configuration.
Step 1 - Here is an example of a starting point, where we have an ESXi host with 2 pNICs (vmnic0 and vmnic1) connected to an LACP bundle which is then associated with a physical switch.