Yellow Bricks

by Duncan Epping

Where’s the HA enforce VM-Host and Affinity rules option in vSphere 6.5?

· ·

Last week on (VMware internal) Socialcast someone asked where the UI option is in vSphere 6.5 that allows you to enable the ability for vSphere HA to respect VM-Host Affinity and VM-VM Anti Affinity rules. In vSphere 6.0 there is an option in the Rules part of the UI as shown in the screenshot below.

In vSphere 6.5 that option has disappeared completely. The reason for this is because vSphere HA now respects these rules by default, as it appeared this is the behavior customers wanted anyway. Note, that if for whatever reason vSphere HA cannot respect the rule it will restart the VMs (violating the rule) as these are non-mandatory rules it chooses availability over compliance in this situation.

If you would like to disable this behavior and don’t care about these rules during a fail-over you can set either or both advanced settings:

  • das.respectvmvmantiaffinityrules – set to “true” by default, set to “false” if you want to disable it
  • das.respectvmhostsoftaffinityrules – set to “true” by default, set to “false” if you want to disable it

I hope that helps those looking to make changes to this behavior.

vSAN Health Check fails on vMotion check

· ·

On Slack someone asked why the vMotion check for vSAN 6.6 Health Check was failing constantly. It was easy to reproduce when using the vMotion IP Stack on your vMotion VMkernel interface. I went ahead and tested it in my lab, and indeed this was the case. I looked around and then noticed the following in the vSAN 6.6 release notes:

vMotion network connectivity test incorrectly reports ping failures
The vMotion network connectivity test (Cluster > Monitor > vSAN > Health > Network) reports ping failures if the vMotion stack is used for vMotion. The vMotion network connectivity (ping) check only supports vmknics that use the default network stack. The check fails for vmknics using the vMotion network stack. These reports do not indicate a connectivity problem.

Workaround: Configure the vmknic to use the default network stack. You can disable the vMotion ping check using RVC commands. For example: vsan.health.silent_health_check_configure -a vmotionpingsmall

I guess that clarifies things, so I figured I would test it. Here’s what it looked like before I disabled the checks:

I used RVC to disable the checks, let me show two methods:

vsan.health.silent_health_check_configure -a vmotionpingsmall /localhost/VSAN-DC/computers/VSAN-Cluster

Note that you will need to replace the “VSAN-DC/..” with your cluster and datacenter name. This disables the vMotion ping test. The other is running this command in interactive mode, that will allow you to simply enter the number of the specific test that needs to be disabled. It will list all tests for you first though.

vsan.health.silent_health_check_configure -i /localhost/VSAN-DC/computers/VSAN-Cluster

The vMotion tests are somewhere half down:

44: vMotion: Basic (unicast) connectivity check
45: vMotion: MTU check (ping with large packet size)

And of course this doesn’t only apply to the vMotion tests, with vSAN 6.6 (vCenter 6.5.0d) you can also disable any of the other tests. Just use the “interactive” mode and disable what you want / need to disable.

<UPDATE>

Note that you can now also disable health checks in the UI as shown in the GIF below. Click it to watch it!

Disk format change going from 6.x to vSAN 6.6?

· ·

Internally I received a comment around the upgrade to 6.6 and the disk format version change. When you upgrade to 6.6 also the version of  disk changes, it goes to version 5. In the past with these on-disk format changes a data move was needed and the whole disk group would be reformat. When going from vSAN 6.2 (vSphere 6.0 U2 that is!) to vSAN 6.6 there is no data move needed. The update is simply a metadata update, and on the average cluster will take less than 20 minutes.

When introducing encryption in to the environment you will need to evac data though as this will be a reformat of the disk. Reason for it being is that the disk will need to be encrypted and so will the data. This doesn’t mean however that if you want to “rekey” your environment a full format and data move is needed, vSAN Encryption has the ability to do a so called “shallow rekey” which means that the Key Encryption Key (KEK) will be replaced (see animated gif below), but not the Data Encryption Key (DEK). It is possible to do a deep rekey, but this will mean a full reformat and data evac of all disk groups. I hope that clears things up.

Where to find the Host Client vSAN section?

· ·

I had a couple of people asking already, so I figured I would do a short post on where to find the ESXi Host Client vSAN section. It is fairly straight forward, if you know where to click. Open the Host Client by going to https://<ip address of your host>/ui. Next do the following:

  • Click on “Storage”
  • In the right pane, click on “vSAN Datastore”
  • In the left pane, click on “Monitor”

You should now see the following:

I drew a red rectangle around the vSAN specific menu options. Just click through them. Just for demonstration purposes I disabled the VMkernel interface for vSAN on this host. As you can see in the “Hosts” section below this particular host has no “IP” address indicating you should check the network… Very useful for sure when troubleshooting.

Of, of course the Health Check and the new Config Assist option vCenter also calls this out! With a link to the object even to fix the issue. If you would click the blue link you would go to the VMkernel config section in the UI… I love it how easy it becomes to fix and detect issues. Great work vSAN team!

vSAN 6.6 available now

· ·

vSAN 6.6 is available now. Check the release notes before you upgrade! Also note that for vSAN users currently on 6.0 Update 3 – upgrade to vSAN 6.6 is not yet supported. If you like to learn more about vSAN 6.6 check the following material:

Note that vSAN 6.6 comes as a patch release, download the bits here from the vSAN 6.6 landing page: