vSAN 6.6.1: vSAN Build Recommendation Engine Health issue [RESOLVED]

In my previous post about vSAN Build Recommendation Engine Health test, I have concluded that it was a bug in vSAN 6.6.1 that prevented vSAN Health service from properly connecting to the Internet via proxy.

With vCenter Server Appliance 6.5 Update 1d release, I have noticed that one of two warning messages disappeared from the vSphere Web Client leaving that task in the ‘Unexpected vSphere Update Manager (VUM) baseline creation failure‘ state.

After checking vSAN configuration one more, I concluded the following:

  • Internet connectivity for automatic updates of the HCL database has been set up properly (vSAN_Cluster > Configure > vSAN > General):


  • The HCL database is up-to-date and CEIP is enabled (vSAN_Cluster > Configure > vSAN > Health and Performance):



  • Update Manager has proxy settings configured and working (vSAN_Cluster > Update Manager > Go to Admin View > Manage > Settings > Download Settings):



At the same time, the proxy server replaces SSL certificates with its own one signed by the corporate CA when establishing HTTPS connection with the remote peer.

As a result, it causes an error message for the vSAN Build Recommendation Engine Health task as follows (extract from vmware-vsan-health-service.log):

INFO vsan-health[Thread-49] [VsanVumConnection::RemediateVsanClusterInVum] build = {u’release’: {u’baselineName’: u’VMware ESXi 6.5.0 U1 (build 5969303)’, u’isoDisplayName’: u’VMware ESXi Release 6.5.0, Build 5969303′, u’bldnum’: 5969303, u’vcVersion’: [u’6.5.0′], u’patchids’: [u’ESXi650-Update01′], u’patchDisplayName’: u’VMware ESXi 6.5.0 U1 (vSAN 6.6.1, build 5969303)’}}

INFO vsan-health[Thread-49] [VsanVumConnection::_LookupPatchBaseline] Looking up baseline for patch VMware ESXi 6.5.0 U1 (vSAN 6.6.1, build 5969303) (keys: [40], hash: None)…

INFO vsan-health[Thread-49] [VsanVumConnection::_LookupPatchBaseline] Looking up baseline for patch vSAN recommended patch to be applied on top of ESXi 6.5 U1: ESXi650-201712401-BG (keys: [], hash: None)…

ERROR vsan-health[Thread-49] [VsanVumConnection::RemediateAllClusters] Failed to remediate cluster ‘vim.ClusterComputeResource:domain-c61’

Traceback (most recent call last):
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanVumConnection.py”, line 1061, in RemediateAllClusters
performScan = performScan)
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanVumConnection.py”, line 876, in RemediateVsanClusterInVum
patchName, patchMap[chosenRelease])
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanVumConnection.py”, line 373, in CreateBaselineFromOfficialPatches
baseline = self._LookupPatchBaseline(name, keys)
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanVumConnection.py”, line 411, in _LookupPatchBaseline
result = bm.QueryBaselinesForUpdate(update = updateKeys)
File “/usr/lib/vmware-vpx/pyJack/pyVmomi/VmomiSupport.py”, line 557, in <lambda>
self.f(*(self.args + (obj,) + args), **kwargs)
File “/usr/lib/vmware-vpx/pyJack/pyVmomi/VmomiSupport.py”, line 362, in _InvokeMethod
list(map(CheckField, info.params, args))
File “/usr/lib/vmware-vpx/pyJack/pyVmomi/VmomiSupport.py”, line 883, in CheckField
raise TypeError(‘Required field “%s” not provided (not @optional)’ % info.name)
TypeError: Required field “update” not provided (not @optional)

INFO vsan-health[Thread-49] [VsanVumSystemUtil::AddConfigIssue] Add config issue createBaselineFailed

INFO vsan-health[Thread-49] [VsanVumConnection::_DeleteUnusedBaselines] Deleting baseline VMware ESXi 6.5.0 U1 (vSAN 6.6.1, build 5969303) (id 424) because it is unused

INFO vsan-health[Thread-49] [VsanVumSystemUtil::VumRemediateAllClusters_DoWork] Complete VUM check for clusters [‘vim.ClusterComputeResource:domain-c61’]

ERROR vsan-health[Thread-49] [VsanVumConnection::RemediateAllClusters] Failed to remediate cluster

Following the community advice, I decided to add Root CA and subordinate CA certificates (in *.pem format) to the local keystore on vCenter Server Appliance. After copying certificates to /etc/ssl/certs and running the c_rehash command, I added proxy servers to /etc/sysconfig/proxy and rebooted the server.


To test that new configuration works, I used the wget command, and it all seemed to work smoothly.


Regardless of all that changes, I still got error messages with the vSAN Build Recommendation Engine Health test, but this time they looked a bit different:

INFO vsan-health[Thread-11125] [VsanPyVmomiProfiler::InvokeAccessor] Invoke: mo=ServiceInstance, info=content

WARNING vsan-health[Thread-11125] [VsanPhoneHomeWrapperImpl::_try_connect] Cannot connect to VUM. Will retry connection

INFO vsan-health[Thread-11125] [VsanPyVmomiProfiler::InvokeAccessor] Invoke: mo=group-d1, info=name

INFO vsan-health[Thread-11125] [VsanPyVmomiProfiler::InvokeAccessor] Invoke: mo=group-d1, info=name

ERROR vsan-health[Thread-11125] [VsanCloudHealthDaemon::run] VsanCloudHealthSenderThread exception: Exception: HTTP Error 411: Length Required, Url: https://vcsa.vmware.com/ph/api/dataapp/send?_v=1.0&_c=VsanCloudHealth.6_5&_i=<Support_Tag&gt;, Traceback: Traceback (most recent call last):
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthUtil.py”, line 511, in getResponse
resp = proxyOpener.open(*args, **kwargs)
File “/usr/lib/python2.7/urllib2.py”, line 435, in open
response = meth(req, response)
File “/usr/lib/python2.7/urllib2.py”, line 548, in http_response
‘http’, request, response, code, msg, hdrs)
File “/usr/lib/python2.7/urllib2.py”, line 473, in error
return self._call_chain(*args)
File “/usr/lib/python2.7/urllib2.py”, line 407, in _call_chain
result = func(*args)
File “/usr/lib/python2.7/urllib2.py”, line 556, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 411: Length Required
Traceback (most recent call last):
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthDaemon.py”, line 353, in run
self._sendCloudHealthData(clusterUuid, data=data)
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthDaemon.py”, line 321, in _sendCloudHealthData
objectId=clusterUuid, additionalUrlParams=additionalUrlParams)
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthConnector.py”, line 156, in send
dataType=dataType, pluginType=pluginType, url=postUrl)
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthConnector.py”, line 139, in sendRawData
raise ex
VsanCloudHealthHTTPException: Exception: HTTP Error 411: Length Required, Url: https://vcsa.vmware.com/ph/api/dataapp/send?_v=1.0&_c=VsanCloudHealth.6_5&_i=<Support_Tag&gt;, Traceback: Traceback (most recent call last):
File “/usr/lib/vmware-vpx/vsan-health/pyMoVsan/VsanCloudHealthUtil.py”, line 511, in getResponse
resp = proxyOpener.open(*args, **kwargs)
File “/usr/lib/python2.7/urllib2.py”, line 435, in open
response = meth(req, response)
File “/usr/lib/python2.7/urllib2.py”, line 548, in http_response
‘http’, request, response, code, msg, hdrs)
File “/usr/lib/python2.7/urllib2.py”, line 473, in error
return self._call_chain(*args)
File “/usr/lib/python2.7/urllib2.py”, line 407, in _call_chain
result = func(*args)
File “/usr/lib/python2.7/urllib2.py”, line 556, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 411: Length Required

INFO vsan-health[Thread-11125] [VsanCloudHealthDaemon::run] VsanCloudHealthSenderThread done.

vsan-health[Thread-9] [VsanCloudHealthDaemon::_sendExceptionsToPhoneHome] Exceptions for collection/sending exceptions

I thought that the vSAN Health service might try to contact vSphere Update Manager directly, and the proxy settings set on the OS level redirected this request to the Internet proxy instead.

I have added the local domain to the exception list in /etc/sysconfig/proxy and rebooted the server again.


After reading about ‘HTTP Error 411’, the only idea was to add a domain service account and its password to HTTP_PROXY and HTTPS_PROXY lines in /etc/sysconfig/proxy. If the password has special characters, they should be added in ASCII encoding to work correctly.

To my great surprise, all communication issues have been resolved, and the vSAN Health service was able to synchronise data with vSphere Update Manager and online services correctly.



A few minutes later vSAN system baselines and baseline groups appeared in vSphere Update Manager.


Of cause, those modifications in Photon OS configuration files are not supported by VMware and could be overwritten by future updates. Yet I hope engineers and developers are working on better integration between vSAN Health and vSphere Update Manager when vCenter resides behind the proxy.

23/02/2018 – Update 1: Per VMware documentation, a starting point to troubleshoot connectivity to the CEIP web server is to make sure the following prerequisites are met:

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.


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

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.

The future of vSphere: No vCenter for Window and Flash client

vSphere Web Client

This is a logical move for VMware on the urge towards departing from the legacy technologies or third-party dependencies in their core products, and a welcomed one!

As more and more customers get used to VMware vCenter Server Appliance and vSphere Client (HTML5) in their environments, it has been just a matter of time to read news about VMware deprecating vCenter Server for Windows and vSphere Web Client.

On 25th of August 2017 it was officially confirmed the next version of vSphere would be “the terminal release” for those products, as stated in the following articles:

I personally like this change, as it helps a vendor to focus on the cutting edge technologies instead of fixing and patching what was good but not great.

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.0 issue: the VMware Client Integration Plugin has updated its SSL certificate in Firefox

I have noticed that with the recent releases of Mozilla Firefox and Google Chrome, the ability to launch VMware Client Integration Plugin was broken again. vSphere Web Client 6.0 constantly keeps showing a pop-up message as follows:

CIP Issue - 01

It happens because both browsers have removed support for the NPAPI plugins. So it drops some operations in the Web Client, such as deploying OVF or OVA templates and transferring files with the datastore browser.

The only workable solution for this issue I found is to use Firefox 52 Extended Support Release (32-bit version) which will support the NPAPI plugins until early 2018.

Alternatively, vCenter Server Appliance should be upgraded to the version 6.5 where “the VMware Enhanced Authentication Plug-in replaces the Client Integration Plug-in from vSphere 6.0 releases and earlier“, and the NPAPI support does not require.

21/06/2017 – Update 1: This message pops up also when the web-browser is configured to use a proxy server. Switching to ‘no proxy’ mode stops it from appearing.

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

The title of this blog post seems to be a bit provocative, and this has been done for a reason.

I believe many VMware engineers, including myself, were really excited about the Content Library feature introduced in vSphere 6.0. The product itself is not completely new for VMware, as it merges code from the content management feature of vCloud Director.

In What’s New in the VMware vSphere 6.0 Platform whitepaper, VMware states the following:

“The Content Library… centrally manages virtual machine templates, ISO images, and scripts, and it performs the content delivery of associated data from the published catalog to the subscribed catalog at other sites.”

Sounds really cool! Now we can centralise all objects that were previously residing on different datastores in one place, and manage them from vSphere Web Client.

In vSphere 6.5, VMware continues improving and polishing this feature:

“Administrators can now mount an ISO directly from the Content Library, apply a guest OS customization specification during VM deployment, and update existing templates.”

However, this article is not only about embracing the tool provided. 🙂 I would like to share with you three specific examples when it doesn’t work as expected, and possible workarounds.

Issue #1 – Provisioning a virtual machine template with the advanced parameters

Affected platform: vSphere 6.0 prior to Update 3.

It was a great surprise to know that provisioning a virtual machine from a VM template which has advanced parameters set can cause any problems in vSphere 6.0. Although the provisioning operation starts as expected, it shows an error message “Failed to deploy OVF package” at the end of it.


Unfortunately, the Error Report in vSphere Web Client wouldn’t be able to clarify the root cause of this event.


After contacting VMware GSS about this issue (SR # 16255562909) in late 2016, I had been advised that this bug would be addressed in vSphere 6.0 Update 3.

In March 2017 I updated my environment to this version and tested this feature, the VM creation was working smoothly. So it took almost two years for VMware since the Content Library feature was generally available to fix it.

Gladly, vSphere 6.5 does not have this problem at all.

Resolution: Update your environment to vSphere 6.0 Update 3 or newer version.

Issue #2 – Provisioning a virtual machine from the Content Library on the vSAN datastore

Affected platform: vSphere 6.5 Standard.

The issue is not related to the Content Library directly, rather to OVA/OVF provisioning. For some reason, when you create a new VM from the template in vSphere 6.5, it triggers “Call DRS for cross vMotion placement recommendations” task.

If you use vSphere 6.5 Standard, for which the DRS feature is not available, it causes this task to fail with the error message “The operation failed due to The operation is not allowed in the current state.”



The Error Report in vSphere Web Client looks similar to one in the picture below.


In the Known Issues in VMware vSAN 6.6 Release Notes, the vendor states the following:

VM OVF deploy fails if DRS is disabled
If you deploy an OVF template on the vSAN cluster, the operation fails if DRS is disabled on the vSAN cluster. You might see a message similar to the following: The operation is not allowed in the current state.

Workaround: Enable DRS on the vSAN cluster before you deploy an OVF template.

After doing some troubleshooting and trying different scenarios, the only difference with the provisioning task I was able to identify was the VM storage policy. Regardless the way the VM creation was initiated (from the OVA/OVF file, or Content Library template), it was the Virtual SAN Default Storage Policy call for the DRS to perform a cross vMotion check.

For example, if you set the VM storage policy in the Select storage dialogue box to “None”, the OVA/OVF file can be provisioned on the vSAN datastore.


The same happens for the VM template from the Subscribed Content Library when the VM storage policy is “None”.

Unfortunately, this trick doesn’t work with the templates in the Local Content Library.

So I decided to dig a bit dipper into the Content Library structure to see if anything can be done there.

The Content Library keeps its data in the contentlib-GUID folder. Each template has its own subfolder with the unique name. Inside the subfolder, there are few files: a descriptor (*.ovf) and one or more data files (*.vmdk).

In vSphere 6.0 those files are named as descriptor_GUID.ovf and disk-vdcs-Disk_Number_GUID.vmdk.

With vSphere 6.5 the files are self-explanatory: Template_Name_GUID.ovf and Template_Name-Disk_Number_GUID.vmdk.


I compared the descriptor files for the VM templates in the Local and Subscribed Content Libraries, and found they had different vmw:name values in the StorageGroupSection. For the Local Content Library it was a “Virtual SAN Default Storage Policy”, and for the subscribed one it was different.


It all led me to the idea of changing this descriptor for the VM template in the Local Content Library. So I could provision the VMs using one of the workarounds below.


  • When provision from the OVA/OVF file, set the VM storage policy in the Select storage dialogue box as “None”,
  • You can provision from the Subscribed Content Library if it has the VM templates with the VM storage policy different from the “Virtual SAN Default Storage Policy”. Set the VM storage policy in the Select storage dialogue box as “None”,
  • You can provision from the Local Content Library if you edit the descriptor file for the VM template and replace the “Virtual SAN Default Storage Policy” with something else. Set the VM storage policy in the Select storage dialogue box as “None”.

Resolution: The support case has been opened, and I am waiting for VMware to resolve this issue. The ETA for this to be fixed is in vSphere 6.5 Update 1 (please refer to SR # 17393663302 when contacting VMware GSS for the future updates).

To be continued

vSphere 6.x: Force the datastore capability sets update

When a new datastore provisioned to the vSphere environment, it might be a delay in updating the information about the capability sets, and the datastore would be incompatible with a storage policy.


The vCenter Server periodically updates storage data in its database. I couldn’t find the exact time intervals when it occurs. Fortunately, it is possible to force the datastore capability sets update in the vSphere Web Client.

To complete this task, go to the vCenter Manage tab and choose ‘Storage providers’ option. A rescan button is available from the storage system settings.


Clicking on that icon initiates rescan and updates the storage capabilities of the datastore.


Now it is able to place the virtual machines on the datastore.