"No host data available" error in the Hardware Status

So having upgraded our environment and several of our customers as well to vSphere 6.5, we realized that the Hardware Status button under the Monitor tab for the ESXi 6.5 hosts are showing "No host data available" for the sensors.

Well apparently this is a known issue as VMware has created KB 2148520 in relation to it.
Apparently, after upgrade, there is a stale Service ID that needs to be removed.

Here are the steps from the KB.  Below are my screenshots showing the actual steps:

This is a known issue affecting the vCenter Server 6.5.

Currently, there is no resolution.

To work around this issue, remove the stale serviceID:

1. From a Web browser, connect to the vCenter Server Managed Object Browser (MOB) at:
   
   https://vcenter_FQDN.com/cm/mob
   
2. Login as the administrator@vsphere.local user.
3. Click Search.
4. Edit the Value column to only have these lines:
   
   <searchCriteria></searchCriteria>
   
   
5. Click Invoke Method.
6. Press Ctrl+F and search for cis.vws.servicename.
7. Copy the serviceID string directly above cis.vws.servicename.
   
   
   
8. Exit this window.
9. Click UnregisterService.
10. Under the Value column, enter the string copied in step 7.
11. Click Invoke Method.

 My Steps in pictures:

The link for the KB Is here:

  "No host data available" error in the Hardware Status tab after upgrading to vCenter Server 6.5
Let us know how this works for you.

The Vitual SAN host cannot be moved to the destination cluster: destination cluster vim.ClusterComputeResource:domain-### is Virtual SAN disabled

So today while I was teaching class, a student created an interesting problem.  We were doing a lab on DRS where they create a single Host Cluster for DRS and all add their hosts.

Well, one student created his own cluster, apparently checked the box for VSAN cluster in the process, added his host to it, then realized he was supposed to be in the "shared" DRS Host Cluster.

He deleted the cluster he had created, re-added his host to vCenter and when he tried to move his host into the DRS Cluster, he got the following error:

It turns out there was a VSAN datastore created with no disks in it and, his host still had an affiliation with the VSAN Cluster that no longer existed.

To resolve the problem we did the following:

Verification:

1. From Storage inventory view in vCenter, verify a VSAN datastore still exists.
2. If it does, Putty into the ESXi host or access it via its ESXi Shell & execute the command:
   esxcli vsan cluster get
3. If results appear, proceed to the solution ...

Solution:

1. From previous command line (SSH or ESXi Shell) to the affected host, execute the following command:
   esxcli vsan cluster leave
2. Now add the host to the existing Host Cluster...

Both Verification and Solution steps together look like this:

vCenter Server Windows & VCSA 6.5.0d is Out!!

Well that was fast... 5 days after the release of VCSA 6.5.0c, comes 6.5.0d for both Windows & Photon OS versions of vCenter.

Primary reason is bug fix support for VSAN 6.6 that was just released.

What's New

The vCenter Server 6.5.0d release includes new features and bug fixes related to vSAN 6.6. For more information, see the vSAN 6.6 Release Notes and the vSAN 6.6 documentation.

The new build is:
 Name: VMware-VCSA-all-6.5.0-5318154.iso
Release Date: 2017-04-18
Build Number: 5318154

The new patch is:
VMware-vCenter-Server-Appliance-6.5.0.5500-5318154-patch-FP.iso
Download Size:1626.4 MB

The simplest way to install the patch is to use the Update feature in the VAMI interface of the VCSA GUI.
Login to https://<VCSA-IP-or_FQDN>:5480
Click on Update on the left.

You can use the Settings button to setup Automatic Checking for Updates to VCSA.
You can manually check for updates by clicking the Check Updates button.
Once an update is displayed as in the following picture, you can install it.


See also:  http://blog.vmtraining.net/2017/04/vcsa-650c-is-out.html 

VCSA 6.5.0c is Out!

VMware just released a new version and patch for their VCSA 6.5 vCenter Server Appliance.
6.5.0c addresses the Apache BlazeDS security vulnerability.

Resolved Issues

VMware vCenter Server contains a remote code execution vulnerability due the use of BlazeDS to process AMF3 messages. This issue may be exploited to execute arbitrary code when deserializing an untrusted Java object. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the identifier CVE-2017-5641 to this issue.

The new build is:
Name: VMware-VCSA-all-6.5.0-5318112.iso
Release Date: 2017-04-13
Build Number: 5318112

The new patch is:
VMware-vCenter-Server-Appliance-6.5.0.5400-5318112-patch-FP.iso
Download Size:1627.4 MB

The simplest way to install the patch is to use the Update feature in the VAMI interface of the VCSA GUI.
Login to https://<VCSA-IP-or_FQDN>:5480
Click on Update on the left.

You can use the Settings button to setup Automatic Checking for Updates to VCSA.
You can manually check for updates by clicking the Check Updates button.
Once an update is displayed as in the following picture, you can install it.

The installation has a thermometer for completion status.
This particular update requires a reboot when done, which can also be done from inside the VAMI.

More information on the update is here in the Release Notes.

If you prefer the command line method for installing VCSA patches, checkout  KB 2149656:
https://kb.vmware.com/kb/2149656

Stop logging me out of the vSphere Web Client!!

I know VMware has increase the default timeout value in vSphere 5.5 & higher to 120 minutes, but for me, slowly prying my cold dead fingers off the old .NET, C# Windows vSphere Client, it's not long enough ... so here's how to increase it.

I'm pulling the basic information from KB 2040626.  Click here.

Increasing the VMware vSphere Web Client session timeout period

Changes need to be performed on the server/VM hosting vCenter Server.

File locations depending on version:

     vCenter Server 5.x
     Windows 2003 – %ALLUSERSPROFILE%\Application Data\VMware\vSphere Web Client
     Windows 2008/2012 – %ALLUSERSPROFILE%\VMware\vSphere Web Client
     VMware vCenter Server Appliance (VCSA) – /var/lib/vmware/vsphere-client

     vCenter Server 6.x
     Windows 2008/2012 – C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client
     VMware vCenter Server Appliance (VCSA) – /etc/vmware/vsphere-client/

Add this line to the file:

          Note: If the line already exists, verify that the line does not contain a hash (#).

    session.timeout = value
          where value is the timeout value in minutes.

          For example, to set the timeout value to 300 minutes, add the line:

    session.timeout = 300
          Note: To set the client to never time out, specify a negative value or 0.

Restart the vSphere Web Client Services: 

• In Windows operating systems, restart the VMware vSphere Web Client service.
• In the VCSA (vCenter Server Appliance), restart the vsphere-client service.

Note: To restart the vSphere Web Client Service, run these commands:

In the vCenter Server Appliance 5.x:
/etc/init.d/vsphere-client restart

In vCenter Server Appliance 6.x:
service-control --stop vsphere-client
service-control --start vsphere-client

Increasing the VMware vSphere Web Client session timeout period

vSphere Data Protection End-of-Life (VDP EOL) & Goodbye 3rd Party Switches

Well, needing massive changes, VMware's vSphere Data Protection Appliance, even with the addition of the features from VDP Advanced, has proven no match for the plethora of backup Solutions currently on the market.

As a result they have announced the following:

vSphere Data Protection: End of Life

VMware is discontinuing VMware vSphere Data Protection (VDP), a general purpose backup product included with vSphere. VMware vSphere 6.5 is the last release which includes the VDP product.

All existing VDP installations with active Support and Subscription (SnS) will continue to be supported until their End of General Support (EOGS) date. Learn more.

Additionally, they have made this announcement about 3rd Party vSwitches:

Notify Customers: Update on vSphere 3rd Party vSwitch Support

VMware is discontinuing the third party virtual switch (vSwitch) program.
VMware will continue to support the 3rd party virtual switch APIs, and the enablement of a partner's use of these APIs up to the vSphere 6.5 Update 1 and prior vSphere versions, as long as an active support and subscription services contract exists.

All vSphere releases and vSphere 6.5 Update 1 will no longer have third party vSwitch APIs and third party vSwitches will no longer work. View these FAQs to learn more and encourage your customers to migrate to vSphere Distributed Switch using our free tool.

New vSphere 6.0 Version Release this week!

VMware Releases vCenter Server 6.0 Update 3a 

Here's What's New in this release:

What's New

The vCenter Server 6.0 Update 3a release addresses an Apache Struts security vulnerability documented in the Resolved Issues section listed here:

Resolved Issues

• Update to Apache Struts
  Apache Struts is updated to version 2.3.32 to resolve CVE-2017-5638.

The rest of the detail can be found in the Release Notes: Here

===============================================================

If you missed what vSphere 6.0 Update 3 included here's the What's New from it:

What's New

• Support for Transport Layer Security (TLS) protocol: Support for TLSv 1.0, TLSv 1.1, and TLSv 1.2 are enabled by default and configurable for vCenter Server 6.0 Update 3.
  • VMware Syslog Collector on vCenter Server Appliance supports TLSv1.0 only.
  • To configure TLSv 1.0, TLSv 1.1and TLSv 1.2, see KB 2148819.
  • For VMware products supported for TLSv1.0 disablement and the use of TLSv1.1, TLSv1.2, see KB 2145796.
  • Download the TLS configuration script from the Product Download page
  • For known issues related to the TLS protocol, see KB 2148819.

• External database support: vCenter Server now supports the Microsoft SQL Server 2012 Service Pack 3.


• Changes in command-line templates and strings: Updates to command-line interface templates and strings. For information about the changes in the CLI installer, see VMware vCenter Server Appliance 6.0 Update 3 CLI Installer Changelog. For information about deploying and upgrading the vCenter Server Appliance, read the Command-Line Deployment and Upgrade of the VMware vCenter Server Appliance.


• Windows to Linux migration support: With installation and upgrade, migration from vCenter Server Windows 5.5.x to vCenter Server Appliance 6.0 Update 3 is supported. Read the vSphere Migration documentation for more information on migrating VMware vCenter Server to vCenter Server Appliance.


• Updates to time zones in the Linux guest operating system customization: vCenter Server Linux guest operating system customization supports latest time zones. For more information on time zone changes and daylight saving time (DST) changes in Linux guest operating systems, see the Time Zone Database by Internet Assigned Numbers Authority (IANA).


• Updates to time zones in the Windows guest operating system customization: vCenter Server Windows guest operating systems customization supports the latest time zones. For more information on time zone changes and daylight saving time (DST) changes in Windows guest operating systems, see the Microsoft Knowledge Base article 3162835.


• Platform Services Controller: Platform Services Controller of vCenter Server Appliance is installed with 4 GB of memory by default, for fresh install and while upgrading from 5.5.x to 6.0 Update 3.


• Transmission Control Protocol (TCP) over User Datagram Protocol (UDP) for Kerberos operations: For improved performance, use Transmission Control Protocol (TCP) over User Datagram Protocol (UDP) for Kerberos operations when it is a part of the Active Directory. To enable this feature, leave and join a domain for a minor update:
  1. Update your setup to 6.0 Update 3
  2. Leave and join a domain so that udp_preference_limit entry appears in /etc/krb5.conf
  Note: It is applicable for vCenter Server Appliance only. The current setting may remain functional if no operation is performed.
• Resolved Issues: This release of vCenter Server 6.0 Update 3 addresses issues that are documented in the Resolved Issues section.

The rest of the detail can be found in the Release Notes: Here

Please comment on adoption of these updates...

NEW VC, vSphere Client & VDP Version Releases this week from VMware!!

Well, not only has this week seen the belated by one month Patch Tuesday by Microsoft, VMware followed suit with two releases themselves...

VMware vCenter Server Release 6.5b

Updated on: 14 March 2017
vCenter Server 6.5.0b | 14 MARCH 2017 | ISO Build 5178943
vCenter Server Appliance 6.5.0b | 14 MARCH 2017 | ISO Build 5178943
vCenter Server 6.5.0b on Windows | 14 MARCH 2017 | ISO Build 5178943

http://pubs.vmware.com/Release_Notes/en/vsphere/65/vsphere-vcenter-server-650b-release-notes.html

You can use the link to see everything, but here's What's New:
This release of vCenter Server 6.5.0b delivers a number of bug fixes that have been documented in the Resolved Issues section.

• Updates to time zones in the Linux Guest Operating System customization. vCenter Server Linux guest operating system customization supports latest time zones. For more information on time zone changes and daylight saving time (DST) changes in Linux guest operating systems, see the Time Zone Database by Internet Assigned Numbers Authority (IANA).
• Updates to time zones in the Windows Guest Operating System customization. vCenter Server Windows guest operating systems customization supports the latest time zones. For more information on time zone changes and daylight saving time (DST) changes in Windows guest operating systems, see the Microsoft Knowledge Base article 3162835.
• Updates to JRE package. The Oracle (Sun) JRE package is updated to version 1.8.0_121 to support Turkish timezone.
• Additional functionality to the vSphere Client. This release delivers additional functionality to the HTML5-based vSphere Client. For more information, see Functionality Updates for the vSphere Client.

Here's more detail on the Updates to the vSphere Sphere Client in VC 6.5b:

First vSphere Client (HTML5) update debuts in VC 6.5b

https://blogs.vmware.com/vsphere/2017/03/first-vsphere-client-html5-update-vsphere-6-5-b.html

New Features – Huge Jump

The online documentation for vSphere 6.5.0b is the best source for detailed documentation on what functionality is now available (http://pubs.vmware.com/Release_Notes/en/vsphere/65/vsphere-client-65-html5-functionality-support.html), but for comparison sake, the bits are just after Fling v3.2, plus a few minor things. The only notable addition beyond v3.2 is the “Accept License” page on OVF deploy, which we specifically pushed into this patch to enable OVF deploy.
This is the list of some of the additional functionality included. Note, some of these features are presented in a partially complete manner. For example, OVF deploy in 6.5.0b will only support URL deployment (no local file). The plan is to fill out all of these features, but the more feedback we get from you regarding what is most important will help us deliver faster.

• OVF Deploy
• Deploy VM from Content Library
• Drag and Drop
• VM conversion to/from templates
• Actions on multiple VMs
• Register VMs
• SDRS management
• Dashboard
• Advanced network operations – Distribute switch, Port group creation
• Datastore create, mount and unmount
• Storage overview
• Host configuration (PCI Passthrough)
• Host profiles compliance monitoring
• Roles and permissions
• Create Tags and categories

Some of these flows may have had minor tweaks to make them easier to use and learn. If you have feedback about any of the new behavior, or missing portions of features, of course let us know using the integrated feedback tool by clicking on the smiley face in the upper righthand corner.

vSphere Data Protection Release 6.1.4 (VDP)

http://pubs.vmware.com/Release_Notes/en/vdp/61/data-protection-614-release-notes.html#fixedproblems

List of fixed problems:

Fixed Problems

The following table lists the problems that have been fixed in this release of vSphere Data Protection:

Defect Number	Description
265470	When you perform an FLR, and you browse for a virtual machine, the vSphere Data Protection GUI displays a misleading error.
268134	A replication recovery job that runs on a target vSphere Data Protection appliance publishes the task by specifying the source server as unknown.
274652	Tivoli Java Collections Library is vulnerable that enables exploitation of port 7778 by running a command on a remote client.
	Fix common vulnerabilities and exposures (CVEs) that are found in third-party libraries by updating vSphere Data Protection appliance with Avamar OS rollup version Q4 2016.
	On vSphere Data Protection appliance, update the Java runtime binaries version to 8u121.
	Provide support for vCenter Server 6.0 U3.
	On vSphere Data Protection appliance, enable TLS 1.2.
	Fix the error, System accounting is not in use: System accounting not found in /etc/cron.d/sysstat.

Failed to Deploy OVF package

Failed to deploy package: File ds:///vmfs/volumes/UUID/_deviceImage-0.iso was not found

While working on setup for a Custom version of our Exchange 2013/2016 Ultimate Bootcamp today, I came across a problem which is not new, but was new to me.

A colleague had saved some VMs to OVA format for deployment in a Master vApp.  As I went to deploy them, I received the following error message:

After doing some research, I came across a couple of articles.  Neither gave me what I needed, but through combining bits and experimenting, I found a solution.

PROBLEM: 

   The VMs had ISOs attached to their CD-ROMs when the were exported to OVA format.
   The OVF file inside the OVA package has information about the attached ISO.

 

SOLUTION:

1. Uncompressed the OVA file using either TAR on Linux/ESXi or 7-Zip on Windows.
2. Located the OVF file which contains the configuration of the VM to deploy.

   
   

   
   

     

3. In the VMname.OVF file, I searched for “vmware.cdrom.iso”
4. I replaced vmware.cdrom.iso with vmware.cdrom.remotepassthrough and saved the file.
   
   
5. Calculated a new SHA1 hash for the updated VMname.OVF file using HashMyFiles (Download here: http://www.nirsoft.net/utils/hash_my_files.html)
   
   
6. Edited the VMname.mf file and replaced the SHA1 hash for the VMname.ovf with the new one & saved the file.
   
      
    
7. Deployed a new VM using the OVF file.
8. Optionally you could repackage the OVF to an OVA using either OVFTool or TAR in a host.
   tar cvf VMname.ova VMname.ovf
   tar uvf VMname.ova *.mf *.vmdk

Another option would be to simply delete the MF file.  vSphere deployment of the OVF then wouldn't do a hash check at all and the install will complete as expected.  Your choice!

Restart VCSA 6.5 Install at Stage 2

Problem: For whatever reason, your install of, migration to or upgrade to VCSA 6.5 stops after completing Stage 1

While teaching class today, I had a student ask if they could restart their VCSA 6.5 installation after Stage 1.  I wasn't sure, so I did some research.

It turns out you can restart at Stage 2. 

All you need to do is access the new VCSA VM created in Stage 1 with:
 https://<VCSA_IP_or_FQDN>:5480
which will redirect to:
 https://<VCSA_IP_or_FQDN:5480/#/installer?locale=en

You will then be presented with the following screen.  Simply click on the appropriate choice to continue...

One reason a Stage 2 pre-upgrade check error may occur is if your source vCenter manages the cluster where you're deploying the new vCenter Server Appliance 6.5, you should specify an ESXi host on the following screen: 

VMware ESXi 6.0 Update 3 Released 2/24/2017!

vSphere 6.0 Update 3 Release Note here...

The major items are the Build number, What's New and Resolved Items.

ESXi 6.0 Update 3 | 24 FEB 2017 | ISO Build 5050593

What's New

• Updated ESXi Host Client: VMware ESXi 6.0 Update 3 includes an updated version of the ESXi Host Client, version 1.14.0. The updated Host Client includes bug fixes and brings it much closer to the functionality provided by the vSphere Client. If you updated the Host Client through ESXi 6.0 patch releases, then install version 1.14.0 provided with ESXi 6.0 U3. In addition, new versions of the Host Client continue to be released through the VMware Labs Flings website. However, these Fling releases are not officially supported and not recommended for production environments.
• Support for TLS: Support for TLSv1.0, TLSv1.1 and TLSv1.2 are enabled by default and configurable for ESXi 6.0 Update 3. Learn how to configure TLSv1.0,TLSv1.1 and TLSv1.2 from VMware Knowledge Base article 2148819. For a list of VMware products supported for TLSv1.0 disablement and the use of TLSv1.1/1.2, consult VMware Knowledge Base article 2145796.
• vSAN Performance: Multiple fixes are introduced in this VMware ESXi 6.0 Update 3 release to optimize I/O path for improved vSAN perfoamance in All Flash and Hybrid configurations:
  
  • Log management and storage improvements were made that enable more logs to be stored per byte of storage. This should significantly improve performance for write-intensive workloads. Because vSAN is a log based file system, efficient management of log entries is key to preventing unwarranted build up of logs.
  • In addition to increasing the packing density of the log entries, for scenarios involving large file being deleted while data services is turned on, vSAN preemptively de-stages data to the capacity tier which efficiently manages the log growth.
  • The checksum code path is now more efficient. 

Resolved Issues

The resolved issues are grouped as follows.

• CIM and API Issues
• Miscellaneous Issues
• Networking Issues
• Security Issues
• Server Configuration Issues
• Storage Issues
• Upgrade and Installation Issues
• Virtual Machine Management Issues
• Virtual SAN Issues
• VMware HA and Fault Tolerance Issues

CIM and API Issues

• The Mware provider method used to validate user permissions does not work for username and password after you exit lockdown mode
  After the server is removed from lockdown mode, the VMware provider method returns a different value that is not compatible with the value before getting into the lockdown mode. The issue results in the VMware provider method to validate user permissions not to work with the same username and password as it did before the lockdown mode. This issue is resolved in this release.

Miscellaneous Issues

• Upgrading VMware Tools on multiple VMs might fail
  Attempts to upgrade VMware Tools on multiple VMs simultaneously through Update Manager might fail. Not all VMs complete the upgrade process. This issue is resolved in this release.

• High read load of VMware Tools ISO images might cause corruption of flash media
  In VDI environment, the high read load of the VMware Tools images can result in corruption of the flash media. This issue is resolved in this release.
  You can copy all the VMware Tools data into its own ramdisk. As a result, the data can be read from the flash media only once per boot. All other reads will go to the ramdisk. vCenter Server Agent (vpxa) accesses this data through the /vmimages directory which has symlinks that point to productLocker.
  To activate this feature, follow the steps:
  
  1. Use the command to set the advanced ToolsRamdisk option to 1:
  esxcli system settings advanced set -o /UserVars/ToolsRamdisk -i 1
  
  2. Reboot the host.

• The syslog.log file might get flooded with Unknown error messages
  In ESXi 6.0 update 2, hosts with Dell CIM provider can have their syslog.log file flooded with Unknown error messages if the Dell CIM provider is disabled or in an idle state. Also, when the ESXi 6.0 update 2 host reboots, the syslog.log file might log error messages intermittently with Unknown entries. This issue is resolved in this release.

• Userworld core dump failure
  A userworld dump might fail when a user process runs out of memory. The error message, Unable to allocate memory, is displayed. This issue is resolved in this release. The fix provides a global memory for heap allocation of userworld core dump, which is used when any process runs out of memory.

• Attempts to run failover for a VM fail with an error when synchronizing storage
  Attempts to run failover for a VM might fail with an error message similar to the following during the synchonize storage operation:
  
  An error occurred while communicating with the remote host.
  
  The following messages are logged in the HBRsrv.log file:
  
  YYYY-MM-DDT13:48:46.305Z info hbrsrv[nnnnnnnnnnnn] [Originator@6876 sub=Host] Heartbeat handler detected dead connection for host: host-9
  YYYY-MM-DDT13:48:46.305Z warning hbrsrv[nnnnnnnnnnnn] [Originator@6876 sub=PropertyCollector] Got WaitForUpdatesEx exception: Server closed connection after 0 response bytes read; 171:53410'>, >)>
  
  Also on the ESXi host, the hostd service might stop responding with messages similar to the following:
  
  YYYY-MM-DDT13:48:38.388Z panic hostd[468C2B70] [Originator@6876 sub=Default]
  -->
  --> Panic: Assert Failed: "progress >= 0 && progress <= 100" @ bora/vim/hostd/vimsvc/HaTaskImpl.cpp:557
  --> Backtrace:
  --> This issue is resolved in this release.

• Log messages persistently reported in the hostd.log file every 90 seconds
  Log messages related to Virtual SAN similar to the following are logged in the hostd.log file every 90 seconds even when the Virtual SAN is not enabled:
  
  { YYYY-MM-DDT06:50:01.923Z info hostd[nnnnnnnn] [Originator@6876 sub=Hostsvc opID=21fd2fe8] VsanSystemVmkProvider : GetRuntimeInfo: Complete, runtime info: (vim.vsan.host.VsanRuntimeInfo) {
  YYYY-MM-DDT06:51:33.449Z info hostd[nnnnnnnn] [Originator@6876 sub=Hostsvc opID=21fd3009] VsanSystemVmkProvider : GetRuntimeInfo: Complete, runtime info: (vim.vsan.host.VsanRuntimeInfo) {
  YYYY-MM-DDT06:53:04.978Z info hostd[nnnnnnnn] [Originator@6876 sub=Hostsvc opID=21fd3030] VsanSystemVmkProvider : GetRuntimeInfo: Complete, runtime info: (vim.vsan.host.VsanRuntimeInfo) { This issue is resolved in this release.

• Upgrading VMware Tools on multiple VMs might fail
  Attempts to upgrade VMware Tools on multiple VMs simultaneously through Update Manager might fail. If this issue occurs, VMware Tools for some VMs might not be upgraded. This issue is resolved in this release.

Networking Issues

• ARP request packets might drop
  ARP request packets between two VMs might be dropped if one VM is configured with guest VLAN tagging and the other VM is configured with virtual switch VLAN tagging, and VLAN offload is turned off on the VMs.

• ESXi firewall configuration might get disabled due to scripted upgrade
  The ESXi firewall configuration might be disabled after scripted upgrade of ESXi 6.0 Update 1 or later using kick start file over NFS or FTP. This issue is resolved in this release.

• The virtual MAC address of 00:00:00:00:00:00 is used during communication for a newly added physical NIC even after a host reboot
  A newly added physical NIC might not have the entry in the esx.conf file after a host reboot, resulting in a virtual MAC address of 00:00:00:00:00:00 listed for physical NIC during communication. This issue is resolved in this release.

• Error message displayed during the boot stage
  Under certain conditions while the ESXi installer reads the installation script during the boot stage, an error message similar to the following is displayed:
  
  VmkNicImpl::DisableInternal:: Deleting vmk0 Management Interface, so setting advlface to NULL This issue is resolved in this release.

• Physical switch flooded with RARP packets when using Citrix VDI PXE boot
  When you boot a virtual machine for Citrix VDI, the physical switch is flooded with RARP packets (over 1000) which might cause network connections to drop and a momentary outage. This release provides an advanced option /Net/NetSendRARPOnPortEnablement. You need to set the value for /Net/NetSendRARPOnPortEnablement to 0 to resolve this issue.

• An ESXi host might fail with purple diagnostic screen
  An ESXi host might fail with purple diagnostic screen. This happens when DVFilter_TxCompletionCB() is called to complete a dvfilter share memory packet, it frees the IO complete data stored inside the packet, but sometimes, this data member becomes 0 which causes a NULL pointer exception. An error message similar to the following is displayed:
  
  YYYY-MM-DDT04:11:05.134Z cpu24:33420)@BlueScreen: #PF Exception 14 in world 33420:vmnic4-pollW IP 0x41800147d76d addr 0x28
  PTEs:0x587e436023;0x587e437023;0x587e438023;0x0;
  YYYY-MM-DDT04:11:05.134Z cpu24:33420)Code start: 0x418000800000 VMK uptime: 23:18:59:55.570
  YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461bdd0:[0x41800147d76d]DVFilterShmPacket_TxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0x3d sta
  YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461be00:[0x41800146eaa2]DVFilterTxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0xbe stack: 0x0
  YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461be70:[0x418000931688]Port_IOCompleteList@vmkernel#nover+0x40 stack: 0x0
  YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bef0:[0x4180009228ac]PktListIOCompleteInt@vmkernel#nover+0x158 stack: 0x0
  YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bf60:[0x4180009d9cf5]NetPollWorldCallback@vmkernel#nover+0xbd stack: 0x14
  YYYY-MM-DDT04:11:05.137Z cpu24:33420)0x43915461bfd0:[0x418000a149ee]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0 This issue is resolved in this release.

Security Issues

• Update to the Likewise Kerberos
  The Likewise Kerberos is updated to version 1.14.

• Update to OpenSSL
  The OpenSSL is updated to version openssl-1.0.2j.

• Update to PAM
  The PAM is updated to version 1.3.0.

• Update to the libPNG library
  The libPNG library is updated to libpng-1.6.26.

• Update to the NTP package
  The ESXi NTP package is updated to version 4.2.8p9.

• Update to the libcurl library
  The ESXi userworld libcurl library is updated to libcurl- 7.51.0.

Server Configuration Issues

• Connectivity to ESXi host is lost from vCenter Server when host profile is reapplied to a stateless ESXi host
  When a host profile with vmknic adapters in both vSphere Standard Switch and vSphere Distributed Switch is applied to an ESXi host, it might remove the vmknic adapter vmk0 (management interface) from vSphere Standard Switch which could result in the host being disconnected from vCenter Server. This issue is resolved in this release.

• The hostd service might fail when taking quiesced snapshot
  The hostd service might fail when performing a quiesced snapshot operation during replication process. An error message similar to the following appears in the hostd.log file: 2016-06-10T22:00:08.582Z [37181B70 info 'Hbrsvc'] ReplicationGroup will retry failed quiesce attempt for VM (vmID=37) 2016-06-10T22:00:08.583Z [37181B70 panic 'Default'] --> -->Panic: Assert Failed: "0" @ bora/vim/hostd/hbrsvc/ReplicationGroup.cpp:2779 This issue is resolved in this release.

• ESXi 6.0 Update 1 hosts might fail with a purple diagnostic screen when collecting statistics
  ESXi hosts with a large number of physical CPUs might stop responding during statistics collection. This issue occurs when the collection process attempts to access pages that lie beyond the range initially assigned to it. This issue is resolved in this release.

• ESXi patch update might fail with a warning message if the image profile size is larger than set limit
  An ESXi patch update installation might fail if the size of the target profile file is larger than 239 MB. This might happen when you upgrade the system using ISO causing image profile size larger than 239MB without getting any warning message. This will prevent any additional VIBs from being installed on the system. This issue is resolved in this release.

• The vmkernel.log file is spammed with multiple USB suspend and resume events
  The vmkernel.log file is spammed with multiple USB resumed and suspended events similar to the following:
  
  YYYY-MM-DDT cpu28:33398)<6>hub 2-1.7:1.0: resumed
  YYYY-MM-DDT cpu28:33398)<6>hub 2-1.7:1.0: suspended
  YYYY-MM-DDT cpu28:33398)<6>hub 2-1.7:1.0: resumed
  YYYY-MM-DDT cpu28:33398)<6>hub 2-1.7:1.0: suspended
  YYYY-MM-DDT cpu28:33398)<6>hub 2-1.7:1.0: resumed
  YYYY-MM-DDT cpu28:33398)<6>hub 2-1.7:1.0: suspended
  YYYY-MM-DDT cpu28:33398)<6>hub 2-1.7:1.0: resumed
  YYYY-MM-DDT cpu28:33398)<6>hub 2-1.7:1.0: suspended
  This issue is resolved in this release.

• Unable to see the user or group list for assigning permissions in the Permission tab
  Unable to see the users or groups list for assigning permissions in the Permission tab and authentication might fail for the trusted domain's user. The issue occurs when the DNS domain name of a machine is different from the DNS name of the AD domain. This issue is resolved in this release. However, after you upgrade the ESXi host to ESXi 6.0 Update 3, you must remove it from the AD domain and re-add it to the same domain.

• ESXi host might stop responding and display a purple diagnostic screen
  When the Dump file set is called using the esxcfg-dumppart or other commands multiple times in parallel, an ESXi host might stop responding and display a purple diagnostic screen with entries similar to the following as a result of a race condition while dump block map is freed up:
  
  @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4907 - Corruption in dlmalloc
  Code start: 0xnnnnnnnnnnnn VMK uptime: 234:01:32:49.087
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]PanicvPanicInt@vmkernel#nover+0x37e stack: 0xnnnnnnnnnnnn
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Panic_NoSave@vmkernel#nover+0x4d stack: 0xnnnnnnnnnnnn
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DLM_free@vmkernel#nover+0x6c7 stack: 0x8
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Heap_Free@vmkernel#nover+0xb9 stack: 0xbad000e
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Dump_SetFile@vmkernel#nover+0x155 stack: 0xnnnnnnnnnnnn
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]SystemVsi_DumpFileSet@vmkernel#nover+0x4b stack: 0x0
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_SetInfo@vmkernel#nover+0x41f stack: 0x4fc
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_Set@#+0x394 stack: 0x0
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@#+0xb4 stack: 0xffb0b9c8
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0x0
  0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry_@vmkernel#nover+0x0 stack: 0x0
  This issue is resolved in this release.

Storage Issues

• Unable to remove stale Virtual Volume volumes and VMDK files using esxcli vvol abandonedvvol command
  Attempts use the esxcli storage vvol storagecontainer abandonedvvol command to clean the stale Virtual Volume volume and the VMDK files that remain on the Virtual Volume volume are unsuccessful. This issue is resolved in this release.

• Snapshot creation task cancellation for Virtual Volumes might result in data loss
  Attempts to cancel snapshot creation for a VM whose VMDKs are on Virtual Volumes datastores might result in virtual disks not getting rolled back properly and consequent data loss. This situation occurs when a VM has multiple VMDKs with the same name and these come from different Virtual Volumes datastores.
  This issue is resolved in this release.

• VMDK does not roll back properly when snapshot creation fails for Virtual Volumes VMs
  When snapshot creation attempts for a Virtual Volumes VM fail, the VMDK is tied to an incorrect data Virtual Volume. The issue occurs only when the VMDK for the Virtual Volumes VM comes from multiple Virtual Volumes datastores. This issue is resolved in this release.

• VM I/O operations stall or cancel when the underlying storage erroneously returns a miscompare error during periodic VMFS heartbeating.
  VMFS uses the SCSI compare-and-write command, also called ATS, for periodic heartbeating. Any miscompare error during ATS command execution is treated as a lost heartbeat and the datastore initiates a recovery action. To prevent corruption, all I/O operations on the device are canceled. When the underlying storage erroneously reports miscompare errors during VMFS heartbeating, the datastore initiates an unnecessary recovery action.
  This issue is resolved in this release.

• ESXi 6.x hosts stop responding after running for 85 days
  When this problem occurs, the /var/log/vmkernel log file displays entries similar to the following:
  
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:34255)qlnativefc: vmhba2(5:0.0): Recieved a PUREX IOCB woh oo
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:34255)qlnativefc: vmhba2(5:0.0): Recieved the PUREX IOCB.
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): sizeof(struct rdp_rsp_payload) = 0x88
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674qlnativefc: vmhba2(5:0.0): transceiver_codes[0] = 0x3
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): transceiver_codes[0,1] = 0x3, 0x40
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): Stats Mailbox successful.
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): Sending the Response to the RDP packet
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674 0 1 2 3 4 5 6 7 8 9 Ah Bh Ch Dh Eh Fh
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)--------------------------------------------------------------
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 53 01 00 00 00 00 00 00 00 00 04 00 01 00 00 10
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) c0 1d 13 00 00 00 18 00 01 fc ff 00 00 00 00 20
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 00 00 00 88 00 00 00 b0 d6 97 3c 01 00 00 00
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 0 1 2 3 4 5 6 7 8 9 Ah Bh Ch Dh Eh Fh
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)--------------------------------------------------------------
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 02 00 00 00 00 00 00 80 00 00 00 01 00 00 00 04
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 18 00 00 00 00 01 00 00 00 00 00 0c 1e 94 86 08
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 0e 81 13 ec 0e 81 00 51 00 01 00 01 00 00 00 04
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 2c 00 04 00 00 01 00 02 00 00 00 1c 00 00 00 01
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 00 00 00 40 00 00 00 00 01 00 03 00 00 00 10
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 50 01 43 80 23 18 a8 89 50 01 43 80 23 18 a8 88
  YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 01 00 03 00 00 00 10 10 00 50 eb 1a da a1 8f This issue is caused by a qlnativefc driver bug sending a Read Diagnostic Parameters (RDP) response to the HBA adapter with an incorrect transfer length. As a result, the HBA adapter firmware does not free the buffer pool space. Once the buffer pool is exhausted, the HBA adapter is not able to further process any requests causing the HBA adapter to become unavailable. By default, the RDP routine is initiated by the FC Switch and occurs once every hour, resulting in the buffer pool being exhausted in approximately 80 to 85 days under normal circumstances.
  This issue is resolved in this release.

• In vSphere 6.0, the HostMultipathStateInfoPath object of the Storage Policy API provides path value as Run Time Name vmhbaX:CX:TX:LX
  In ESXi 5.5, HostMultipathStateInfoPath provided path information in this format: HostWWN-ArrayWWN-LUN_ID, For example, sas.500605b0072b6550-sas.500c0ff1b10ea000-naa.600c0ff0001a20bd1887345701000000. However, in ESXi 6.0, the path value appears as vmhbaX:CX:TX:LX, which might impact users who rely on the HostMultipathStateInfoPath object to retrieve information such as HostWWN and ArrayWWN. This issue is resolved in this release. The HostMultipathStateInfoPath object now displays the path information as Run Time Name and HostWWN-ArrayWWN-LUN_ID.
  You can also use the esxcli storage core path list command to retrieve the path related information. This command provides the HostWWN and ArrayWWN details. For more information, see the Knowledge Base article 1003973.

• An ESXi host might fail with a purple diagnostic screen
  An ESXi host with vFlash configured might fail with a purple diagnostic screen and an error message similar to PSOD: @BlueScreen: #PF Exception 14 in world 500252:vmx-vcpu-0:V. This issue is resolved in this release.

• ESXi host fails with a purple diagnostic screen due to path claiming conflicts
  An ESXi host displays a purple diagnostic screen when it encounters a device that is registered, but whose paths are claimed by a two multipath plugins, for example EMC PowerPath and the Native Multipathing Plugin (NMP). This type of conflict occurs when a plugin claim rule fails to claim the path and NMP claims the path by default. NMP tries to register the device but because the device is already registered by the other plugin, a race condition occurs and triggers an ESXi host failure. This issue is resolved in this release.

• File operations on large files fails as the host runs out of memory
  When you perform file operations such as mounting large files present on a datastore, these operations might fail on an ESXi host. This situation can occur when a memory leak in the buffer cache causes the ESXi host to run out of a memory, for example, when a non-zero copy of data results in buffers not getting freed. An error message similar to the following is displayed on the virtual machine.
  
  The operation on file /vmfs/volumes/5f64675f-169dc0cb/CloudSetup_20160608.iso failed. If the file resides on a remote file system, make sure that the network connection and the server where this disk resides are functioning properly. If the file resides on removable media, reattach the media. Select Retry to attempt the operation again. Select Cancel to end this session. Select Continue to forward the error to the guest operating system. This issue is resolved in this release.

• Horizon View recompose operation might fail for desktop VMs residing in NFS datastore
  Horizon View recompose operation might fail for a few desktop VMs residing in NFS datastore with Stale NFS file handle error. This issue is resolved in this release.

Upgrade and Installation Issues

• Upgrading ESXi with vSphere Update Manager fails if ESXi was deployed using dd image on USB and /altbootbank contains BOOT.CFG in upper case
  An ESXi dd image generated on certain versions of RHEL by using the esxiso2dd utility can contain BOOT.CFG in upper case in /altbootbank. If BOOT.CFG is in upper case, vSphere Update Manager fails to upgrade the host because the upgrade pre-checker accepts boot.cfg in lowercase only. This issue is resolved in this release.

• Hostd fails when you upgrade ESXi 5.5.x hosts to ESXi 6.0.x with the ESXi 6.0 patch ESXi600-201611011 or higher
  You can observe this issue when you have installed an asynchronous HPSA driver that supports HBA mode. Although ESXi supports getting HPSA disk location information in HBA mode, problems might occur when one of the following conditions is met:
  
  
  • You installed an old hpssacli utility, version 2.10.14.0 or older.
  • You used an external array to connect the HPSA controller.
  These problems lead to hostd failures and the host becoming unreachable by vSphere Client and vCenter Server.
  This issue is resolved in this release. When you now use the esxcli command to get the disk location information, hostd does not fail. The esxcli command returns an error message similar to the following:
  # esxcli storage core device physical get -d naa.500003963c888808 Plugin lsu-hpsa-plugin cannot get information for device with name naa.500003963c888808. Error was: Invalid output for physicaldrive.

• vSphere Update Manager upgrade of ESXi booted with dd image on USB might fail when /altbootbank contains BOOT.CFG (uppercase) instead of boot.cfg (lowercase)
  ESXi dd image generated on certain versions of RHEL using esxiso2dd utility contains BOOT.CFG (in uppercase) in /altbootbank, presence of BOOT.CFG causes vSPhere Update Manager upgrade of ESXi to fail because the upgrade pre-check looks for boot.cfg in lowercase only.
This issue is resolved in this release.

• After upgrade to 6.0, the Image Profile name in the summary tab of the host is not updated properly
  When you use the esxcli software profile update command to apply a new Image Profile, the image profile name does not change to the new image profile name. Also when you use the ISO to perform the upgrade, the new image profile name is not marked as Updated. This issue is resolved in this release.

Virtual Machine Management Issues

• vSphere Update Manager sends reboot reminders for VMware Tools when reboot already occurred after installation
  The VMware Tools installation error code displays that a reboot is required even after the reboot occurred after VMware Tools was installed. The guestInfo.toolsInstallErrCode variable on the virtual machine executable (VMX) side is not cleared when VMware Tools is successfully installed and reboot occurs. This causes vSphere Update Manager to send incorrect reminders to reboot VMware Tools. This issue is resolved in this release.

• Hostd fails when ListProcesses run on guest operating system
  When a large number of processes are present in a guest operating system, the ListProcesses process is invoked more than once and the data from VMware Tools arrives in multiple chunks. When multiple ListProcesses calls to the guest OS (one for every chunk) are assembled together, the implementation creates a conflict. Multiple ListProcesses identify when all the data arrived and calls an internal callback handler. Calling the handler twice results in the failure of hostd. This issue is resolved in this release.

• Possible data corruption or loss when a guest OS issues SCSI unmap commands and an IO filter prevents the unmap operation
  When a VM virtual disk is configured with IO filters and the guest OS issues SCSI unmap commands, the SCSI unmap commands might succeed even when one of the configured IO filters failed the operation. As a result, the state reflected in the VMDK diverges from that of the IO filter and data corruption or loss might be visible to the guest OS. This issue is resolved in this release.

• An ESXi host might fail with purple diagnostic screen
  When a DVFilter_TxCompletionCB() operation attempts to complete a dvfilter share memory packet, it frees the IO complete data member stored inside the packet. In some cases, this data member becomes 0, causing a NULL pointer exception. An error message similar to the following is displayed:
  
  YYYY-MM-DDT04:11:05.134Z cpu24:33420)@BlueScreen: #PF Exception 14 in world 33420:vmnic4-pollW IP 0x41800147d76d addr 0x28 PTEs:0x587e436023;0x587e437023;0x587e438023;0x0; YYYY-MM-DDT04:11:05.134Z cpu24:33420)Code start: 0x418000800000 VMK uptime: 23:18:59:55.570 YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461bdd0:[0x41800147d76d]DVFilterShmPacket_TxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0x3d sta YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461be00:[0x41800146eaa2]DVFilterTxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0xbe stack: 0x0 YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461be70:[0x418000931688]Port_IOCompleteList@vmkernel#nover+0x40 stack: 0x0 YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bef0:[0x4180009228ac]PktListIOCompleteInt@vmkernel#nover+0x158 stack: 0x0 YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bf60:[0x4180009d9cf5]NetPollWorldCallback@vmkernel#nover+0xbd stack: 0x14 YYYY-MM-DDT04:11:05.137Z cpu24:33420)0x43915461bfd0:[0x418000a149ee]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0 This issue is resolved in this release.

• ESXi host with PCI passthru might stop responding and display a purple diagnostic screen
  When you reboot a VM with PCI Passthru multiple times, the ESXi host might stop responding and display a purple diagnostic screen with messages similar to the following in the vmware.log file:
  
  XXXXXXXXXXXXXXX| vcpu-0| W110: A core file is available in "/vmx-debug-zdump.000"
  XXXXXXXXXXXXXXX| vcpu-0| I120: Msg_Post: Error
  XXXXXXXXXXXXXXX| vcpu-0| I120: [msg.log.error.unrecoverable] VMware ESX
  XXXXXXXXXXXXXXX| vcpu-0| unrecoverable error: (vcpu-0)
  XXXXXXXXXXXXXXX| vcpu-0| I120+ vcpu-7:ASSERT vmcore/vmm/intr/intr.c:459 This issue is resolved in this release.

• The hostd service might fail during replication process
  The hostd service might fail when a quiesced snapshot operation fails during replication process. An error message similar to the following might be written to the hostd.log file:
  
  YYYY-MM-DDT22:00:08.582Z [37181B70 info 'Hbrsvc'] ReplicationGroup will retry failed quiesce attempt for VM (vmID=37)
  YYYY-MM-DDT22:00:08.583Z [37181B70 panic 'Default']
  -->
  --> Panic: Assert Failed: "0" @ bora/vim/hostd/hbrsvc/ReplicationGroup.cpp:2779 This issue is resolved in this release.

• The hostd service might stop responding if it encounters I/O failures for a VM provisioned with an LSI virtual SCSI controller
  An ESXi host might stop responding if it encounters storage I/O failures for a VM provisioned with an LSI virtual controller and memory is overcommitted on the ESXi host. This issue is resolved in this release.

Virtual SAN Issues

• Intermittent failures in Virtual SAN cluster operations related to provisioning or resulting in new object creation
  A memory leak in the Cluster Level Object Manager Daemon (CLOMD) results in memory exhaustion over a long runtime causing the daemon to become temporarily unavailable. This issue is resolved in this release.

• DOM module fails to initialize
  Description: The Cluster Level Object Manager Daemon (CLOMD) might not use Virtual SAN on an ESXi host with large number of physical CPUs. This issue can occur if the Virtual SAN DOM module fails to initialize when joining a cluster. An error message similar to the following is displayed in the clomd.log file:
  2016-12-01T22:34:49.446Z 2567759 Failed to run VSI SigCheck: Failure 2016-12-01T22:34:49.446Z 2567759 main: Clomd is starting 2016-12-01T22:34:49.446Z 2567759 main: Is in stretched cluster mode? No 2016-12-01T22:34:49.446Z 2567759 CLOMSetOptions: Setting forground to TRUE 2016-12-01T22:34:49.446Z 2567759 CLOMSetOptions: No default configuration specified. 2016-12-01T22:34:49.447Z 2567759 main: Starting CLOM trace 2016-12-01T22:34:49.475Z 2567759 Cannot open DOM device /dev/dom: No such file or directory 2016-12-01T22:34:49.475Z 2567759 Cannot connect to DOM: Failure 2016-12-01T22:34:49.475Z 2567759 CLOM_CleanupRebalanceContext: Cleaning up rebalancing state 2016-12-01T22:34:49.481Z 2567759 Failed to dump data 2016-12-01T22:34:49.481Z 2567759 2016-12-01T22:34:49.481Z 2567759 main: clomd exit
  This issue is resolved in this release.

• ESXi host fails to rejoin VMware Virtual SAN cluster after a reboot
  Attempts to rejoin the VMware Virtual SAN cluster manually after a reboot might fail with the following error:
  
  Failed to join the host in VSAN cluster (Failed to start vsantraced (return code 2) This issue is resolved in this release.

• Constant calling of VSAN API might result in display of a misleading task message
  In an environment with vCenter Server 6.0 Update 2 and Virtual SAN 6.2, calling the VSAN API constantly results in creation of tasks for registering a ticket to Virtual SAN VASA provider and a message similar to the following is displayed:
  
  Retrieve a ticket to register the Virtual SAN VASA Provider This issue is resolved in this release.

• Virtual SAN Disk Rebalance task halts at 5% for more than 24 hours
  The Virtual SAN Health Service reports Virtual SAN Disk Balance warnings in the vSphere Web Client. When you click Rebalance disks, the task appears to halt at 5% for more than 24 hours. This issue is resolved in this release and the Rebalance disks task is shown as completed after 24 hours.

• ESXi host might stop responding and display a purple diagnostic screen
  An ESXi host might stop responding and display a purple diagnostic screen with messages similar to the following:
  
  YYYY-MM-DDT22:59:29.686Z cpu40:84493)@BlueScreen: #PF Exception 14 in world 84493:python IP 0xnnnnnnnnnnnn addr 0xfffffffffffffff0 PTEs:0x0;
  YYYY-MM-DDT22:59:29.686Z cpu40:84493)Code start: 0xnnnnnnnnnnnn VMK uptime: 7:15:08:48.373
  YYYY-MM-DDT22:59:29.686Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DOMClient_IsTopObject@com.vmware.vsan#0.0.0.1+0x18 stack: 0xnnnnnnnn
  YYYY-MM-DDT22:59:29.687Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DOMListUuidTopHierarchyCbk@com.vmware.vsan#0.0.0.1+0x69 stack: 0x900
  YYYY-MM-DDT22:59:29.687Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSANUUIDTable_Iterate@com.vmware.vsanutil#0.0.0.1+0x4b stack: 0x139d
  YYYY-MM-DDT22:59:29.687Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DOMVsi_ListTopClients@com.vmware.vsan#0.0.0.1+0x5a stack: 0x66
  YYYY-MM-DDT22:59:29.688Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_GetListInfo@vmkernel#nover+0x354 stack: 0xnnnnnnnnnnnn
  YYYY-MM-DDT22:59:29.688Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_GetList@#+0x216 stack: 0xnnnnnnnnn
  YYYY-MM-DDT22:59:29.688Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@#+0xb4 stack: 0xnnnnnnn
  YYYY-MM-DDT22:59:29.689Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0x0
  YYYY-MM-DDT22:59:29.689Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry_@vmkernel#nover+0x0 stack: 0x0 This issue is resolved in this release.

• ESXi hosts might fail with a purple diagnostic screen
  ESXi hosts in a Virtual SAN Cluster might fail with a purple diagnostic screen when a Virtual SAN resync operation is paused. This issue is resolved in this release.

VMware HA and Fault Tolerance Configuration Issues

• ESXi host might fail when enabling fault tolerance on a VM
  An ESXi host might fail with a purple diagnostic screen when a Fault Tolerance Secondary VM fails to power on. This issue is resolved in this release.

• vSphere Guest Application Monitoring SDK fails for VMs with vSphere Fault Tolerance enabled
  When vSphere FT is enabled on an vSphere HA-protected VM where the vSphere Guest Application Monitor is installed, the vSphere Guest Application Monitoring SDK might fail. This release significantly reduces the increase in the VM network latency when Fault Tolerance is enabled.

• Increased latency when SMP Fault Tolerance is enabled on a VM
  When symmetric multiprocessor (SMP) Fault Tolerance is enabled on a VM, the VM network latency might go up significantly in both average and variations. The increased latency might result in significant performance degradation or instability for VM workloads that are sensitive to such latency increases. This release significantly reduces the increase in the VM network latency when Fault Tolerance is enabled.