vSphere Web Client 6.x: ‘Shockwave Flash has crashed’ issue

It was a great surprise for many virtualisation specialists to see an error message saying ‘Shockwave Flash has crashed’ immediately after authenticating in the vSphere Web Client 6.x earlier this week.

Flash-Issue-01

Most of the reports came from those who were using the latest version of Google Chrome (61.0.3163.100). However, there were similar issues with other web-browsers and Adobe Flash version 27.0.0.170.

William Lam wrote a special post on his blog about this issue, and he keeps it updated with the number of hacks.

Gladly, VMware has been quick with publishing a KB 2151945 which tracks information about the same problem and providing some workarounds as well. Thanks to Dennis Lu for pointing to this article!

This is a classic example of how dependency on a third-party technology can affect your solution. I hope that VMware accelerates the development of vSphere Client (HTML5) and provides feature parity between it and the Flash one.

ESXi 6.5: Host fails with PSOD after upgrading to 6.5 Update 1

For those who have plans upgrading their environment from vSphere 6.0 to 6.5 Update 1, I would suggest postponing this until VMware resolves issue documented in KB 2151749.

ESXi650-2151749

Hosts will be affected if they equipped with 10 Gbps NICs.

The only workaround that the vendor has at the moment is to downgrade ESXi to 6.0 Update 2.

17/10/2017 – Update 1: According to VMware GSS, this issue is going to be “resolved in ESXi 6.5 Patch 02, which is schedule to release this month (The release date may change without notice).” Please refer to the SR #17599111410 when contacting GSS for more information.

vSAN 6.6.1: vSAN Build Recommendation Engine Health fails

As you might already know, vSAN 6.6.1 is the first release with automated build recommendations for vSAN clusters for vSphere Update Manager, which should help to keep your hardware in a supported state by comparing information from the VMware Compatibility Guide and vSAN Release Catalog with information about the installed ESXi releases.

Obviously, this feature requires vSAN to have Internet access to update release metadata, as well as valid My VMware credentials to download ISO images for upgrades.

To help customers with enabling vSAN build recommendations, VMware embedded some health checks into vSAN 6.6.x that contribute to resolve configuration issues. The build recommendation engine health check detects the following states:

  • Internet access is unavailable.
  • vSphere Update Manager (VUM) is disabled or is not installed.
  • VUM is not responsive.
  • vSAN release metadata is outdated.
  • My VMware login credentials are not set.
  • My VMware authentication failed.
  • Unexpected VUM baseline creation failure.

If the virtual environment seats behind the proxy, you should configure proxy settings in the Internet Connectivity option in vSAN_ClusterConfigure > vSAN > General.

vSAN Health Engine Issue - 02

Those parameters are kept in /etc/vmware-vsan-health/config.conf. Be careful with the user password, as it is added to this file without any encryption.

To test access through the proxy, you can click on the Get latest version online button in vSAN_ClusterConfigure > Health and Performance to update the HCL Database. If everything setup correctly, it will generate the following lines in /var/log/vmware/vsan-health/vmware-vsan-health-service.log:

INFO vsan-health[ID] [<user_name> op=UpdateHclDbFromWeb obj=VsanHealthService] Update HCL database from Web
INFO vsan-health[ID] [VsanHclUtil::_getHttpResponse] Download via proxy

However, even if the Internet connection works, the vSAN Build Recommendation Engine Health test will produce a warning message as follows:

vSAN Health Engine Issue - 01

In the log file you will see lines like these:

WARNING vsan-health[healthThread-c3ad57ea-a3f1-11e7] [VsanCloudHealthUtil::checkNetworkConnection] Internet is not connected.

File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthDaemon.py”, line 337, in run
profiler=self.profiler):
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthDaemon.py”, line 279, in collectedResults
VsanCloudHealthCollector.updateManifestWithPerCluster(serviceInstance)
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthDaemon.py”, line 230, in updateManifestWithPerCluster
cls._updateManifest()
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthDaemon.py”, line 190, in _updateManifest
manifestVersion = cls._queryManifestVersion()
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthDaemon.py”, line 174, in _queryManifestVersion
dataType=’manifest_version’, objectId=MANIFEST_VERSION_UUID)
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthConnector.py”, line 209, in getClusterHealth
maxRetries=maxRetries, waitInSec=waitInSec)
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthConnector.py”, line 247, in getObject
responseBody = self._getPhoneHomeResultsWithRetries(urlParams)
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthConnector.py”, line 279, in _getPhoneHomeResultsWithRetries
raise e
VsanCloudHealthConnectionException: <urlopen error [Errno 110] Connection timed out>

Apparently, it is a bug in the current version of vSAN that is documented in the VMware KB 2151692. Neither fix nor workaround is available at the time of writing this blog post.

vSphere 6.5 Update 1 has been released!

VMware has just released a major update to vCenter Server 6.5 with a plenty of exciting features including:

  • Ability to run the vCenter Server Appliance GUI and CLI installers on Microsoft Windows 2012 x64 bit, Microsoft Windows 2012 R2 x64 bit, Microsoft Windows 2016 x64 bit, and macOS Sierra
  • vSAN software upgrades through integration with vSphere Update Manager
  • Support for Microsoft SQL Server 2016, Microsoft SQL Server 2016 SP1, and Microsoft SQL Server 2014 SP2 as external databases for vCenter Server
  • Improved HTML5-based vSphere Client
  • Increased configuration maximums for the Linked vCenter Server instances
  • vSphere Replication updates
  • Driver updates and hips of resolved issue.

The following products have been updated:

Updated packages can be found here.

More information about new features is available following those links:

I have a few support requests with VMware GSS open, which should be resolved in this release of the product.

Will keep you posted after upgrading my environment and finishing testing.

vSphere 6.x: The beauty and ugliness of the Content Library – Part 2

In part 1 of this mini-series, I wrote about some technical problems that I had had with the Content Library and provided the workable solutions for them.

Here I am going to touch the security aspect of this technology. Fortunately, there are no complications with restricting the virtual machine provisioning. It is just not as straightforward, as I or some of the readers would expect.

Issue #3 – Preventing users from provisioning the virtual machine from the Content Library

Affected platform: vSphere 6.0 and 6.5, all versions.

In vCenter, permissions are assigned to objects in the object hierarchy called vSphere Inventory Hierarchy. The individual permissions are called privileges. They are combined into roles which then allocated to the users.

The Content Library has its own set of privileges under All Privileges > Content Library. They designed to manage different settings related to the configuration of the object. There is a predefined role in vSphere called Content Library Administrator. The primary purpose of it is to give a user privileges to monitor and manage a library and its contents.

However, if you would like to restrict the VM provisioning from the Content Library and look at the long list, there is no privilege which can help to achieve this task there.

After doing some testing and discussing this subject with VMware GSS, the only solution we were able to come up was removing all Content Library privileges from the role and assigning it to the users on the vCenter Server level. In this case, users won’t be able to get access to the items in the Content Library. I was a bit frustrated with this limitation and even contacted the engineering team at VMware directly about the issue.

Coincidentally, I was working on restricting the VM provisioning from other sources: vApps and OVA/OVF Templates. It was then I realised it was actually possible to implement the complete solution to my problem.

As you might know, the Content Library keeps the VM template objects in OVF format.

CL-02

So I decided to play with the privileges that control deploying process from OVF templates. Surprisingly, it was a vApp import that helped me to achieve my goal. Happy days!

CL-03

Resolution: Remove All Privileges > vApp > Import privilege from the user role, as described in VMware KB 2105932.