Yellow Bricks

1 May, 2017 Leave a Comment

Can I front vSAN with a VAIO Caching Solution?

I had this question a couple of times already, so I figured I would write a quick post. In short: yes you can put a VAIO Filter in front of vSAN. The question really is, which one would you like to use and why?

First of all, the VAIO Filter needs to be certified to be placed in front of vSAN storage. Just like it needs to be certified for VMFS and NFS. You can go to the VAIO HCL and check this yourself:

Go to: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vaio
Select the Vendor, for instance Infinio
Then click the product that comes up and open up the version of vSphere you want to use it for, for instance 6.5
Now it should state something like this : VMFS5, vSAN, VVOL

In this example Infinio supports VVols, vSAN and VMFS. Great! Now the next question is: why? Well that is the bigger question, personally I don’t see a real compelling reason. For traditional storage it makes a lot of sense, as you want to keep IOs local and add cache in a “cheap way” instead of expanding, a potentially close to end of life, storage system. For vSAN that is different. vSAN has a distributed architecture and every node has a flash device that is being used for write caching, and also read caching in a hybrid scenario. If this is a new deployment invest your money in NVMe instead. If you want to repurpose existing hardware and it is not on the vSAN HCL, ask yourself if you should complicate your deployment or not?

I would personally recommend to keep it simple, but than again I can also understand you do not want to let flash resources go to waste if vSAN does not support the devices. If you want to go VAIO, make sure to check the HCL and take the potential risks and operational complexity in to account and weigh that against the cost.

25 April, 2017 Leave a Comment

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 tries to respect these rules by default, as it appeared this is the behaviour 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 choses availability over compliancy in this situation.

If you would like to disable this behaviour 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 behaviour.

21 April, 2017 6 Comments

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.