VSAN – Page 34

Override default VSAN Maintenance (decommission) Mode in VSAN 6.1

09.14.2015 by William Lam // Leave a Comment

Earlier this year, there was an interesting use case that was brought up from a customer regarding the use of vSphere Update Manager (VUM) and VSAN enabled ESXi hosts. Everything was working from a functional standpoint, but the customer wanted a way to control the default VSAN decommission mode which specifies how the data should be moved, if at all when a host is placed into maintenance mode. There are three supported options which includes Ensure Accessibility (default), Evacuate All Data and No Action. Depending on the customer and their use case, there may be valid reasons to use one or the other. For example, if I am shutting down my entire VSAN cluster for some hardware upgrade, I probably do not want any of my data to be migrated and the No Action setting would be acceptable. During an upgrade or patching an of ESXi host, some customers have expressed that they would prefer to leverage the Evacuate All Data setting which is perfectly fine, of course the maintenance mode would take long as all the dat must be migrated off the host first.

Prior to VSAN 6.1 (included in the vSphere 6.0 Update 1 release), it was not possible to override the default VSAN maintenance mode (decommission mode) option which defaults to Ensure Accessibility. This was a problem because if you decided you wanted to use a different option, there would be some manual intervention required from the user when using VUM. The workaround for the customer would be to either manually or using the vSphere API to automate the ESXi host maintenance mode operation and specify the decommission mode type before VUM would take over and update the host. Not an ideal solution but would work if you needed to override the default.

I thought this would be a nice feature enhancement to be able to override the default VSAN maintenance mode option which could vary from customer to customer depending on their use case. I got in touch with one of the VSAN Engineers to discuss the use case in more detail and he agreed that it would be useful to expose this type of a capability. In VSAN 6.1, there is now a new ESXi Advanced Setting called DefaultHostDecommissionMode which allows you to specify the default VSAN maintenance mode behavior.

Below is a table of the three available options (ensureAccessibility is default) that can be configured:

VSAN Decommission Mode Value	Description
ensureAccessibility	VSAN data reconfiguration should be performed to ensure storage object accessibility
evacuateAllData	VSAN data evacuation should be performed such that all storage object data is removed from the host
noAction	No special action should take place regarding VSAN data

This ESXi Advanced Setting can also be retrieved and configured using ESXCLI as well as the vSphere API.

To retrieve the current VSAN maintenance mode option using ESXCLI, run the following command:

esxcli system settings advanced list -o /VSAN/DefaultHostDecommissionMode

To configure the default VSAN maintenance mode option using ESXCLI, run the following command:

esxcli system settings advanced set -o /VSAN/DefaultHostDecommissionMode -s [DECOMISSION_MODE]

How to deploy and run the VSAN 6.1 Witness Virtual Appliance on VMware Fusion & Workstation?

09.11.2015 by William Lam // 20 Comments

One of the most exciting new feature in VSAN 6.1 is the new Stretched Clustering capability which also provides support for a 2-Node ROBO deployment. If you are interested in learning more about the new VSAN 6.1 capabilities, be sure to check out Duncan's blog post here as well as a video on how to configure the new VSAN Stretched Clustering here. Like many of you, I am sure you are looking forward to giving both vSphere 6.0 Update 1 as well as the new VSAN 6.1 capabilities a spin in your home lab or development environment. By now, you probably know how easy it is to run Nested ESXi on top of your existing vSphere environment. However, not everyone has access to a vSphere environment. The next best thing is using VMware Fusion and Workstation which also supports Nested ESXi and for many of our customers and field, it is a great solution as it allows you to easily play with all the VMware goodies while you are on the go, especially useful if you travel frequently.

[Read more...]

How to download offline VSAN HCL file for VSAN Health Check Plugin?

05.16.2015 by William Lam // 4 Comments

One of the coolest features in the new VSAN Health Check Plugin is the automatic verification of your underlying hardware (hosts, disks, storage controller & drivers) by automatically checking it against VMware's VSAN HCL (Hardware Compatibility List).

The VSAN HCL database can either be downloaded automatically from VMware.com or manually uploaded if you do not have direct or proxy internet access. There was a question this morning on Twitter asking where the offline VSAN HCL file be downloaded from? I was actually curious as well and looking at Cormac Hogan's excellent VSAN Health Check documentation, I found the answer at the very end of the document 🙂

http://partnerweb.vmware.com/service/vsan/all.json

To download the offline VSAN HCL file which is actually is just a JSON file, you just need to load the above URL into a web browser and then save the file.

After you have downloaded the VSAN HCL file, you can either upload using the vSphere Web Client under the "Health" section of the VSAN Health Plugin or you using the following RVC command and specifying the path to the file:

vsan.health.hcl_update_db /localhost/ -l /root/all.json

As a bonus, I also had some fun parsing the VSAN HCL JSON file. Below is a graph that I was able to generate after extracting some useful information using the following script found here.