Previously I discussed default settings regarding Horizon View linked-clone machines and their Failures To Tolerate (FTT) setting on a Virtual SAN cluster. Today I want to talk about performing maintenance on a VSAN cluster hosting a Horizon View environment. This is mostly in regards to maintenance that requires a reboot of the host, e.g. BIOS/firmware updates. I recently had a memory module fail on a host that caused it to be unable to boot until the module was removed. This causes faults with Horizon View in several different ways. The primary one I want to discuss is an error regarding the Composer server being unable to connect with all the hosts in the cluster being used.

While it is possible to place a host in a VSAN cluster supporting View into maintenance mode, it does not appear to be possible to reboot the host without causing the View composing process to fail. This is what happened several times during the maintenance process I went through while attempting to restore functionality to my cluster after the memory module failed. I found that if I removed the host from the cluster I was able to continue composing desktops without error, however.

I later brought this up with a Horizon View support engineer and the statement made was that View is very intolerant of vSphere issues, which I can absolutely confirm. Composer will fail immediately on any fault. If Composer is expecting a host to be available and it sees that it is not, then it will fail. There is an option that you can uncheck in the View Pool configuration named “Stop provisioning on error” that will cause the pool to continue to attempt to compose desktops. I would recommend that this setting not be disabled because it can cause issues when there is an error. The pool will continue to attempt to compose desktops even if there is an unrecoverable error. This can thrash resources and generally makes repairing the pool more difficult. This option is under the Provisioning Settings tab in the configuration window.

What I have found is that, because the error is centered around the host being part of the cluster, it is easy to just put the host in maintenance mode, kick the host out of the cluster, do your maintenance, then bring it back in. This allows View to continue to compose desktops uninterrupted.

This isn’t much of a VSAN issue, the Health Service will throw its alarms when you reboot a VSAN node, however nothing actually fails in the VSAN cluster. The issue here is with the View Composer server. I think that if View could ignore hosts in maintenance mode, or hosts whose last known configuration was in maintenance mode, this would allow easier maintenance. As it is, as long as you know that you need to remove the host from the cluster, it isn’t really that big of a deal, however it’s just another little thing that you have to know to run a View cluster properly. Hopefully this helps someone else down the line.