vSphere 6.0 – Page 24

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]

Quick Tip - Fix for CIP no longer functioning in vSphere Web Client after Chrome 45 update

09.11.2015 by William Lam // 39 Comments

For those of you who recently updated to Chrome 45, which apparently I did as well or more likely it automatically did it for me. You may have noticed that the Client Integration Plugin (CIP) for the vSphere Web Client no longer function when you try to upload an OVA or trying to use the Windows Session Authentication feature. The latest release of Chrome has now completely disabled NPAPI support, but luckily there is a simple fix.

You simply just need to download and install the following new version of the CIP package for either Windows or Mac OS X and you will be able to restore the functionality that you once had which no longer relies on NPAPI. This fix applies to both a vSphere 6.0 and vSphere 6.0 Update 1 environment which I was able to test myself as I have both deployed. If you are still having issues after installing the update, make sure you clear your browser cache as the old plugin may still be cached. Some folks had to perform a reboot, especially if you have more than one user on the system which could still have existing running processes.

UPDATE (10/27/15) - For customers running vSphere 5.5.x, the NPAPI fix has just been released as part vCenter Server 5.5 Update 3a. The fix includes both a server side and client side component. This means to apply the fix, you MUST update BOTH the vCenter Server as well as the updated CIP which is provided when logging into the vSphere Web Client. For vSphere 5.0/5.1 customers, the only work around is by following this VMware KB 2114800.

I want to give a big shoutout to my buddy Blair who shared this KB with me as I was having issues after the Chrome update.

Client Integration Plugin for Windows:

http://vsphereclient.vmware.com/vsphereclient/2/9/9/4/0/4/1/VMware-ClientIntegrationPlugin-6.0.0.exe

Client Integration Plugin for Mac OS X

http://vsphereclient.vmware.com/vsphereclient/2/9/9/4/0/4/1/VMware-ClientIntegrationPlugin-6.0.0.mac64.dmg

You can also find more details noted in this VMware KB 2130672. For vSphere 5.5 customers, a back port is currently being worked on but there is currently not an ETA. When is it released, the KB will be updated and you can subscribe to it for the announcement.

Docker Container for testing vSphere 3rd Party Content Library

09.09.2015 by William Lam // Leave a Comment

Last week at VMworld, I co-presented a Technical Deep Dive on vSphere's Content Library feature (INF5106) which was first introduced in our vSphere 6.0 release. One of the demos that I showed case was the 3rd Party Content Library capability which allows you to publish your own Content Library without the need of a vCenter Server. For those of you who attended in person, you may have recalled that I had used a Docker Container to quickly standup an Nginx endpoint for hosting my 3rd Party Content Library.

I have just published my Docker Container called lamw/tp-content-library-demo on Dockerhub . If you wish to build the Docker Container yourself, you can take a look at my Github project vmworld2015-3rd-party-content-library for more details. You can also subscribe to my other 3rd Party Content Library which includes variety of Nested ESXi OVF Templates, for more details you can take a look at the blog post here.

Requirements:

Linux Container Host for running the Docker Container like VMware Photon for example
vSphere 6.0 environment

Instructions:

Step 1 - Download the 3rd Party Content Library Docker Container by running the following command:

docker pull lamw/tp-content-library-demo

Step 2 - Start the Docker Container by running the following command:

docker run -d -p 80:80 lamw/tp-content-library-demo

Step 3 - Verify that the Nginx webserver is properly running by visiting the following URL (replace with the IP Address/Hostname of your Container Host): http://192.168.1.143/vghetto/

If everything was setup correctly, you should see a variety of files from our sample 3rd Party Content Library along with the various JSON metadata files describing the library itself.

Step 4 - To subscribe to the 3rd Party Content Library, go ahead and create a new Content Library using the vSphere Web Client and start off by specifying the name of the Content Library you wish to create.

Step 5 - Next, go select the "Subscribed content library" option and paste in the following URL: http://[CONTAINER-HOST-IP]/vghetto/lib.json which is the 3rd Party Content Library endpoint running in our Docker Container.

Step 6 - Lastly, go ahead and select a storage backing for the library. In this case, I have selected a vSphere Datastore and then click finish to create the library.

Once the Content Library has successfully been created, we can then click into it to see that we are no subscribing to the 3rd Party Content Library that we had just hosted on our Nginx Docker Container as seen in the screenshot below.

If you are interested to learning more about the Content Library feature, we will be repeating the Content Library Technical Deep Dive session at VMworld EMEA for those of you who will be attending. Hope to see you there!