View Composer bug

I am building 3 new ESXi hosts to add to an existing 3 host cluster. The cluster is supporting a View install. The backend SAN is a fibre channel VNX. I attached my ethernet and installed ESXi via kickstart. As always, I did not attach the HBAs to ensure no accidental overwrites of a VMFS datastore.

I joined my 3 new hosts to the cluster and ran Update Manager to get them patched and up to date. While that ran, I started looking at zoning the fibre switches. As I did that, a problem with the desktop image was reported to me. I fixed the image, took a snapshot, and went to recompose my test pool to validate that the fix worked. The recompose fails with “View Composer Fault: VMware.Sim.Fault.VcDatastoreInaccessibleFault”

Hmm. I checked all three existing hosts and they were able to see all datastores. A quick Google search turned up KB2001736. The article states “This issue occurs when one or more hosts in the cluster do not have access to a datastore required by the pool. You may also encounter this if one of the hosts is in maintenance mode.”

This article doesn’t seem to convey the seriousness of the problem. View composer will fail to recompose if ANY host in your cluster loses access to the storage. It doesn’t matter if the host is in maintenance mode or not. I performed several tests to validate and they were consistent – any host with all paths down causes Composer to bomb.

Evicting the offending host from the cluster is the only solution. While this isn’t a major problem for my brand new hosts, it is inconvenient. For an actual production host, it is quite annoying. If you have a failing HBA, you can’t recompose unless you evict the host. This causes you to lose all of your historic performance statistics. Again, not a showstopper – but it’s not a choice you should have to make. View Composer should ignore hosts in maintenance mode.