VMware has the HTML5 vSphere/vCenter Client constantly under development. Yet, would you use it? Would I? The client is woefully incomplete for the entire VMware product suite but seems to have the basics done well. Here are a few tips for keeping this client up to date, as well as what seems to be missing for day-to-day use.
At the moment, I am waiting for several updates on VMware products to allow an upgrade to vSphere 6.5. Specifically, I am waiting on an upgrade of NSX and VIN that are supported by vSphere 6.5. The other tools I use should be fine with 6.5, but without those, I cannot upgrade. The vSphere Upgrade Saga continues with the following updates.
I run multiple iSCSI servers, ranging from HPE StoreVirtual (must trusted) and Synology Server (tertiary server) to my own CentOS 7 base iSCSI server (least trusted). All run over 10GB links. In general, iSCSI usually works quite well. But for some reason, my CentOS 7 iSCSI server would cause the management agents to fail and vSphere to disconnect from vCenter. This would go on until the iSCSI server was shut down. I use those 10TBs of storage for testing data protection tools and for emergencies. This is a bad thing for the continued support of generic iSCSI. This is also a vSphere Upgrade Saga entry.
Currently, the VMware vCenter Server Appliance (vCSA) requires a Windows helper VM. This helper VM can be loaded with a number of different items, most notably vSphere Update Manager (VUM) and VMware Horizon View Composer. The services this VM can contain are listed later in this article. Suffice it to say, the helper VM (or VMs) become critical to your environment. I was running W2K8 R2 but decided to move to W2K12 R2. This was more of an effort than I had imagined. Most things worked just fine, but it took a bit of research to find out why some items did not work. See my previous article vSphere Upgrade Saga: vCSA Helper VM for the first part of this series.
In my previous vSphere Upgrade Saga post, VSAN Upgrade Woes, I discussed upgrade problems in a relatively unsupported configuration. I finally figured out why I had such a problem. It was not the unsupported nature of the configuration, but the disk space used within VSAN. In effect, my VSAN was heavily overcommitted, and as such, there was no room to move things around to allow updates. I needed a new implementation of VSAN, one that is supported.
The upgrade to VSAN 6.2 did not go as smoothly as I wished. It was possible to do but required me to rebuild not only VSAN but my cluster as a whole as a rolling upgrade did not work as expected. Perhaps this is just the way I have my VSAN configured.