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.

Windows: Three ways to map a network drive using PowerShell

This subject is not directly related to virtualisation. However, it can be useful when you are not going to utilise Group Policy, and still need to automate drive mapping.

The old school

net use <drive_letter:> <UNC_path_to_the_network_drive> /persistent:[yes|no]

Pros: simple command that works.

Cons: not native to PowerShell; can be deprecated in the future.

Documentation: https://technet.microsoft.com/en-us/library/bb490717.aspx.

PowerShell 3.0+

New-PSDrive -Name <drive_name> -Root <UNC_path_to_the_network_drive> -PSProvider FileSystem -Scope [Global|Local] -Persist:[$true|$false]

New-PSDrive creates temporary and persistent mapped network drives. The scope should be set to allow other applications properly use mapped drives.

Pros: native to PowerShell.

Cons: require PowerShell 3.0+ to be fully functional.

Documentation: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-psdrive.

PowerShell 5.0+

New-SmbMapping -LocalPath <drive_letter:> -RemotePath <UNC_path_to_the_network_drive> -Persistent:[$true|$false]

New-SmbMapping creates a Server Message Block (SMB) mapping on the SMB client to an SMB share.

Pros: native to PowerShell.

Cons: this cmdlet had some issues before PowerShell 5.0.

Documentation: https://docs.microsoft.com/en-us/powershell/module/smbshare/new-smbmapping.

 

vSAN 6.5-6.6.1: An urgent hotfix ESXi650-201710401

VMware has just released a new hotfix for ESXi and vSAN (KB 2151081) urging customers with all-flash configuration with deduplication enabled to upgrade their environment as soon as possible. This patch resolves data corruption issue which might appear in rare circumstances.

ESXi650-201710401

The affected versions of vSAN include 6.5, 6.6, and 6.6.1.

06-10-2017 – Update 1: As listed in KB 2151042, similar issue has been fixed for ESXi 6.0.

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.0: Templates are shown as ‘Unknown’ in the local Content Library

Another day another case… This time, I was surprised to see an empty list when provisioning a new virtual machine from a Content Library.

CL Issue - 01

I went to check the Content Library status and found all templates were shown as ‘Unknown’ in there.

CL Issue - 02

Funny enough, this behaviour was happening only with the local Content Library. A subscribed one didn’t have any issues at all, and the synchronisation between those two was still working.

CL Issue - 03

More interestingly, the objects of other types were not affected at all.

There is not enough information about how to troubleshoot the Content Library in vSphere 6.0. Some of the diagnostic files can be found in the /var/log/vmware/vdcs directory on vCenter Server Appliance (VCSA). Unfortunately, they are not that informative.

So I opened the case with VMware GSS (SR # 17504701707) and the response was that “this issue is occurring as there is a corrupted or stale PID for the content library service which has not been cleared from the previous running state.”

VMware is working on this to be resolved, but no ETA at the moment.

A workaround provided by VMware:

  1. Connect to the vCenter Server Appliance using SSH and root credentials.
  2. Navigate to /var/log/vmware/vdcs.
  3. Create a new folder to move the PID file to.
  4. Move the vmware-vdcs.pid file to the folder created in step 3.
  5. Reboot the vCenter Server Appliance (In case of external PSC, reboot the PSC first and then the vCenter).

I personally found that restarting VCSA resolves this issue. However, it reappears after some time.