VMware

VMware ESXi 5.1 Update 2 Release Notes

VMware ESXi 5.1 Update 2 | 16 JAN 2014 | Build 1483097

Last updated: 26 MAR 2014

Check for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:

What's New

This release of VMware ESXi contains the following enhancements:

  • Support for additional guest operating systems This release updates support for many guest operating systems.
    For a complete list of guest operating systems supported with this release, see the VMware Compatibility Guide.

  • Resolved Issues This release also delivers a number of bug fixes that have been documented in the Resolved Issues section.

Earlier Releases of ESXi 5.1

Features and known issues of ESXi 5.1 are described in the release notes for each release. To view release notes for earlier releases of ESXi 5.1, see the

Internationalization

VMware vSphere 5.1 Update 2 is available in the following languages:

  • English
  • French
  • German
  • Japanese
  • Korean
  • Simplified Chinese

Compatibility and Installation

Upgrading vSphere Client

After you upgrade vCenter Server or the ESXi host to vSphere 5.1 Update 2 and attempt to connect to the vCenter Server or the ESXi host using a version of vSphere Client earlier than 5.1 Update 1b, you are prompted to upgrade the vSphere Client to vSphere Client 5.1 Update 2. The vSphere Client upgrade is mandatory. You must use only the upgraded vSphere Client to access vSphere 5.1 Update 2.

ESXi, vCenter Server, and vSphere Web Client Version Compatibility

The VMware Product Interoperability Matrix provides details about the compatibility of current and previous versions of VMware vSphere components, including ESXi, VMware vCenter Server, the vSphere Web Client, and optional VMware products. In addition, check this site for information about supported management and backup agents before installing ESXi or vCenter Server.

The vSphere Client and the vSphere Web Client are packaged with the vCenter Server and modules ZIP file. You can install one or both clients from the VMware vCenter™ Installer wizard.

ESXi, vCenter Server, and VDDK Compatibility

Virtual Disk Development Kit (VDDK) 5.1.2 adds support for ESXi 5.1 Update 2 and vCenter Server 5.1 Update 2 releases. For more information about VDDK, see http://www.vmware.com/support/developer/vddk/.

Hardware Compatibility for ESXi

To determine which processors, storage devices, SAN arrays, and I/O devices are compatible with vSphere 5.1 Update 2, use the ESXi 5.1 Update 2 information in the VMware Compatibility Guide.

The list of supported processors is expanded for this release. To determine which processors are compatible with this release, use the VMware Compatibility Guide.

Guest Operating System Compatibility for ESXi

To determine which guest operating systems are compatible with ESXi 5.1 Update 2 , use the ESXi 5.1 Update 2 information in the VMware Compatibility Guide.

Beginning with vSphere 5.1, support level changes for older guest operating systems have been introduced. For descriptions of each support level, see Knowledge Base article 2015161. The VMware Compatibility Guide provides detailed support information for all operating system releases and VMware product releases.

The following guest operating system releases that are no longer supported by their respective operating system vendors are deprecated. Future vSphere releases will not support these guest operating systems, although vSphere 5.1 Update 2 does support them.

  • Windows NT
  • All 16-bit Windows and DOS releases (Windows 98, Windows 95, Windows 3.1)
  • Debian 4.0 and 5.0
  • Red Hat Enterprise Linux 2.1
  • SUSE Linux Enterprise 8
  • SUSE Linux Enterprise 9 prior to SP4
  • SUSE Linux Enterprise 10 prior to SP3
  • SUSE Linux Enterprise 11 Prior to SP1
  • Ubuntu releases 8.04, 8.10, 9.04, 9.10 and 10.10
  • All releases of Novell Netware
  • All releases of IBM OS/2

Virtual Machine Compatibility for ESXi

Virtual machines that are compatible with ESX 3.x and later (hardware version 4) are supported with ESXi 5.1 Update 2 . Virtual machines that are compatible with ESX 2.x and later (hardware version 3) are no longer supported. To use such virtual machines on ESXi 5.1 Update 2 , upgrade the virtual machine compatibility. See the vSphere Upgrade documentation.

Installation Notes for This Release

Read the vSphere Installation and Setup documentation for step-by-step guidance on installing and configuring ESXi and vCenter Server.

Although the installations are straightforward, several subsequent configuration steps are essential. In particular, read the following:

Migrating Third-Party Solutions

You cannot directly migrate third-party solutions installed on an ESX or ESXi host as part of a host upgrade. Architectural changes between ESXi 5.0 and ESXi 5.1 result in the loss of third-party components and possible system instability. To accomplish such migrations, you can create a custom ISO file with Image Builder. For information about upgrading with third-party customizations, see the vSphere Upgrade documentation. For information about using Image Builder to make a custom ISO, see the vSphere Installation and Setup documentation.

Upgrades and Installations Disallowed for Unsupported CPUs

vSphere 5.1 Update 2 supports only CPUs with LAHF and SAHF CPU instruction sets. During an installation or upgrade, the installer checks the compatibility of the host CPU with vSphere 5.1 Update 2. If your host hardware is not compatible, a purple screen appears with an incompatibility information message, and you cannot install or upgrade to vSphere 5.1 Update 2.

Upgrades for This Release

For instructions about upgrading vCenter Server and ESX/ESXi hosts, see the vSphere Upgrade documentation.

ESXi 5.1 Update 2 offers the following tools for upgrading ESX/ESXi hosts:

  • Upgrade interactively using an ESXi installer ISO image on CD-ROM, DVD, or USB flash drive. You can run the ESXi 5.1 Update 2 installer from a CD-ROM, DVD, or USB flash drive to do an interactive upgrade. This method is appropriate for a small number of hosts.
  • Perform a scripted upgrade. You can upgrade or migrate from version 4.x ESX/ESXi hosts, ESXi 5.0.x, and ESXi 5.1.x hosts to ESXi 5.1 Update 2 by invoking an update script, which provides an efficient, unattended upgrade. Scripted upgrades also provide an efficient way to deploy multiple hosts. You can use a script to upgrade ESXi from a CD-ROM or DVD drive, or by PXE-booting the installer.

  • vSphere Auto Deploy. If your ESXi 5.x host was deployed using vSphere Auto Deploy, you can use Auto Deploy to reprovision the host by rebooting it with a new image profile that contains the ESXi upgrade.

  • esxcli. You can update and apply patches to ESXi 5.1.x hosts by using the esxcli command-line utility,this can be done either from a download depot on vmware.com or from a downloaded ZIP file of a depot that is prepared by a VMware partner. You cannot use esxcli to upgrade ESX or ESXI hosts to version 5.1.x from ESX/ESXI versions earlier than version 5.1.

Supported Upgrade Paths for Upgrade to ESXi 5.1 Update 2 :

Upgrade Deliverables

Supported Upgrade Tools

Supported Upgrade Paths to ESXi 5.1 Update 2

ESX/ESXi 4.0:
Includes
ESX/ESXi 4.0 Update 1
ESX/ESXi4.0 Update 2

ESX/ESXi4.0 Update 3
ESX/ESXi 4.0 Update 4

ESX/ESXi 4.1:
Includes
ESX/ESXi 4.1 Update 1
ESX/ESXi 4.1 Update 2

ESX/ESXi 4.1 Update 3

 

ESXi 5.0:
Includes
ESXi 5.0 Update 1

ESXi 5.0 Update 2
ESXi 5.0 Update 3

ESXi 5.1
Includes
ESXi 5.1 Update 1

VMware-VMvisor-Installer-5.1.0.update02-1483097.x86_64.iso

 

  • VMware vCenter Update Manager
  • CD Upgrade
  • Scripted Upgrade

Yes

Yes

Yes

Yes

update-from-esxi5.1-5.1_update02.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • VMware vSphere CLI

No

No

Yes*

Yes

Using patch definitions downloaded from VMware portal (online)

VMware vCenter Update Manager with patch baseline

No

No

No

Yes

*Note: Upgrade from ESXi 5.0.x to ESXi 5.1 Update 1 using update-from-esxi5.1-5.1_update02.zip is supported only with ESXCLI. You need to run the esxcli software profile update --depot=<depot_location> --profile=<profile_name> command to perform the upgrade. For more information, see the ESXi 5.1.x Upgrade Options topic in the vSphere Upgrade guide.

Open Source Components for VMware vSphere 5.1 Update 2

The copyright statements and licenses applicable to the open source software components distributed in vSphere 5.1 Update 2 are available at http://www.vmware.com/download/open_source.html. You can also download the source files for any GPL, LGPL, or other similar licenses that require the source code or modifications to source code to be made available for the most recent generally available release of vSphere.

Product Support Notices

  • vSphere Client. In vSphere 5.1, all new vSphere features are available only through the vSphere Web Client. The traditional vSphere Client will continue to operate, supporting the same feature set as vSphere 5.0, but not exposing any of the new features in vSphere 5.1 .

    vSphere 5.1 and its subsequent update and patch releases are the last releases to include the traditional vSphere Client. Future major releases of VMware vSphere will include only the vSphere Web Client.

    For vSphere 5.1, bug fixes for the traditional vSphere Client are limited to security or critical issues. Critical bugs are deviations from specified product functionality that cause data corruption, data loss, system crash, or significant customer application down time where no workaround is available that can be implemented.

  • VMware Toolbox. vSphere 5.1 is the last release to include support for the VMware Tools graphical user interface, VMware Toolbox. VMware will continue to update and support the Toolbox command-line interface (CLI) to perform all VMware Tools functions.

  • VMI Paravirtualization. vSphere 4.1 was the last release to support the VMI guest operating system paravirtualization interface. For information about migrating virtual machines that are enabled for VMI so that they can run on later vSphere releases, see Knowledge Base article 1013842.

  • Windows Guest Operating System Customization. vSphere 5.1 is the last release to support customization for Windows 2000 guest operating systems. VMware will continue to support customization for newer versions of Windows guests.

  • VMCI Sockets. Guest-to-guest communications (virtual machine to virtual machine) are deprecated in the vSphere 5.1 release. This functionality will be removed in the next major release. VMware will continue support for host to guest communications.

Patches Contained in this Release

This release contains all bulletins for ESXi that were released earlier to the release date of this product. See the VMware Download Patches page for more information about the individual bulletins.

Patch Release ESXi510-Update02 contains the following individual bulletins:

ESXi510-201401201-UG: Updates ESXi 5.1 esx-base vib
ESXi510-201401202-UG: Updates ESXi 5.1 tools-light vib
ESXi510-201401203-UG: Updates ESXi 5.1 net-tg3 vib
ESXi510-201401204-UG: Updates ESXi 5.1 net-e1000e vib
ESXi510-201401205-UG: Updates ESXi 5.1 scsi-rste vib
ESXi510-201401206-UG: Updates ESXi 5.1 scsi-mpt2sas vib
ESXi510-201401207-UG: Updates ESXi 5.1 sata-ata-piix vib
ESXi510-201401208-UG: Updates ESXi 5.1 sata-ahci vib


Patch Release ESXi510-Update02 Security-only contains the following individual bulletins:

ESXi510-201401101-SG: Updates ESXi 5.1 esx-base vib
ESXi510-201401102-SG: Updates ESXi 5.1 tools-light vib
ESXi510-201401103-SG: Updates ESXi 5.1 esx-xlibs vib

Patch Release ESXi510-Update02 contains the following image profiles:

ESXi-5.1.0-20140102001-standard
ESXi-5.1.0-20140102001-no-tools

Patch Release ESXi510-Update02 Security-only contains the following image profiles:

ESXi-5.1.0-20140101001s-standard
ESXi-5.1.0-20140101001s-no-tools


For information on patch and update classification, see KB 2014447.

Resolved Issues

This section describes resolved issues in this release:

CIM and API

  • ESXi host is disconnected from vCenter Server due to sfcbd exhausting inodes
    ESXi hosts disconnect from vCenter Server and cannot be reconnected to the vCenter Server. This issue is caused by the hardware monitoring service (sfcdb) that populates the /var/run/sfcb directory with over 5000 files.

    The hostd.log file located at /var/log/ indicates that the host is out of space:
    VmkCtl Locking (/etc/vmware/esx.conf) : Unable to create or open a LOCK file. Failed with reason: No space left on device
    VmkCtl Locking (/etc/vmware/esx.conf) : Unable to create or open a LOCK file. Failed with reason: No space left on device


    The vmkernel.log file located at /var/log indicates that the host is out of inodes:
    cpu4:1969403)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process python because the visorfs inode table is full.
    cpu11:1968837)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process hostd because the visorfs inode table is full.
    cpu5:1969403)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process python because the visorfs inode table is full.
    cpu11:1968837)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process hostd because the visorfs inode table is full.

    This issue is resolved in this release.
  • Incorrect error messages might be displayed by CIM providers
    Incorrect error messages similar to the following might be displayed by CIM providers:

    \"Request Header Id (886262) != Response Header reqId (0) in request to provider 429 in process 5. Drop response.\"

    This issue is resolved in this release by updating the error log and restarting the sfcbd management agent to display the correct error messages similar to the following:
    Header Id (373) Request to provider 1 in process 0 failed. Error:Timeout (or other socket error) waiting for response from provider.
  • The hardware monitoring service stops and the Hardware Status tab only displays an error message
    The Hardware Status tab fails to display health statuses and displays an error message similar to the following:

    Hardware monitoring service on this host is not responding or not available.

    The hardware monitoring service (sfcdb) stops and the syslog file contains entries similar to the following:

    sfcb-smx[xxxxxx]: spRcvMsg Receive message from 12 (return socket: 6750210)
    sfcb-smx[xxxxxx]: --- spRcvMsg drop bogus request chunking 6 payLoadSize 19 chunkSize 0 from 12 resp 6750210
    sfcb-smx[xxxxxx]: spRecvReq returned error -1. Skipping message.
    sfcb-smx[xxxxxx]: spRcvMsg Receive message from 12 (return socket: 4)
    sfcb-smx[xxxxxx]: --- spRcvMsg drop bogus request chunking 220 payLoadSize 116 chunkSize 104 from 12 resp 4
    ...
    ...
    sfcb-vmware_int[xxxxxx]: spGetMsg receiving from 40 419746-11 Resource temporarily unavailable
    sfcb-vmware_int[xxxxxx]: rcvMsg receiving from 40 419746-11 Resource temporarily unavailable
    sfcb-vmware_int[xxxxxx]: Timeout or other socket error


    This issue is resolved in this release.
  • WS-Management GetInstance () action might issue a wsa:DestinationUnreachable fault on an ESXi server
    WS-Management GetInstance () action against http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_SoftwareIdentity?InstanceID=46.10000 might issue a wsa:DestinationUnreachable fault on some ESXi server. The OMC_MCFirmwareIdentity object path is not consistent for CIM gi/ei/ein operations on the system with Intelligent Platform Management Interface (IPMI) Baseboard Management Controller (BMC) sensor. As a result, WS-Management GetInstance() action issues a wsa:DestinationUnreachable fault on the ESXi server.

    This issue is resolved in this release.
  • vmklinux_9:ipmi_thread of vmkapimod displays CPU usage as hundred percent for one hour
    In an ESXi host, when reading the Field Replaceable Unit (FRU) inventory data using the Intelligent Platform Management Interface (IPMI) tool, the vmklinux_9:ipmi_thread of vmkapimod incorrectly displays the CPU usage as hundred percent. This is because the IPMI tool uses the Read FRU Data command multiple times to read the inventory data.

    This issue is resolved in this release.
  • Cannot monitor ESXi host's hardware status
    When the SFCBD service is enabled in the trace mode and the service stops running, the Hardware Status tab for an ESXi host might report an error. Any third-party tool might not be able to monitor the ESXi host's hardware status.

    This issue is resolved in this release.
  • Unable to clear Intelligent Platform Management Interface (IPMI) System Event Log (SEL) on the ESXi host
    The host IPMI System Event Log is not getting cleared in a cluster environment.

    This issue is resolved by adding a new CLI support to clear the IPMI SEL.
  • LSI CIM provider leaks file descriptors
    LSI CIM provider (one of sfcb process) leaks file descriptors. This might cause sfcb-hhrc to stop and sfcbd to restart. The syslog file might log messages similar to the following:
    sfcb-LSIESG_SMIS13_HHR[ ]: Error opening socket pair for getProviderContext: Too many open files
    sfcb-LSIESG_SMIS13_HHR[ ]: Failed to set recv timeout (30) for socket -1. Errno = 9
    ...
    ...
    sfcb-hhrc[ ]: Timeout or other socket error
    sfcb-hhrc[ ]: TIMEOUT DOING SHARED SOCKET RECV RESULT ( )


    This issue is resolved in this release.
  • Unable to disable weak ciphers on CIM port 5989
    To disable cipher block chaining (CBC) algorithms for Payment Card Industry (PCI)compliance, you might need to disable weak ciphers on CIM port 5989. This is not permitted.  

    This issue is resolved in this release. You can update the configuration in sfcb.cfg to disable weak ciphers by using the following commands:
    # vi /etc/sfcb/sfcb.cfg
    sslCipherList: HIGH:!DES-CBC3-SHA
    # /etc/init.d/sfcbd-watchdog restart
  • sfcb-CIMXML-Pro freezes and causes a core dump of sfcb-CIMXML-Pro process
    The sfcb-CIMXML-Pro freezes and causes a core dump, when the sfcb sub process for http processing incorrectly calls atexit and exit following a fork command.

    This issue is resolved in this release.

Miscellaneous

  • Some 3D applications display misplaced geometry when the 3D support is enabled on a Windows 7 or Windows 8 virtual machines
    Some 3D applications display misplaced geometry on a Windows 7 or Windows 8 virtual machine if the Enable 3D support option is selected.

    This issue is resolved in this release.
  • Netlogond might stop responding and cause ESXi host to lose Active Directory functionality
    Netlogond might consume high memory in Active Directory environment with multiple unreachable Domain Controllers. As a result, Netlogond might fail and ESXi host might lose Active Directory functionality.

    This issue is resolved in this release.
  • The snmpwalk command for a specific snmp OID fails
    When you run the snmpwalk command for ifHCOutOctets 1.3.6.1.2.1.31.1.1.1.10, an error message similar to the following is displayed:

    No Such Instance currently exists at this OID for ifHCOutOctets 1.3.6.1.2.1.31.1.1.1.10

    This issue is resolved in this release.
  • vSocket driver running on an ESXi host with vShield Endpoint might get into a deadlock
    The vSocket driver might get into a deadlock in a Windows virtual machine running on an ESXi host with vShield Endpoint. A blue diagnostic screen with the following log is displayed:

    esx-B15E102S-2013-07-01--09.54/vmfs/volumes/50477c5b-d5ad9a53-8e9c-047d7ba55d90/B15E030S/vmware.log:
    2013-06-27T20:44:05.812Z| vcpu-0| TOOLS installed legacy version 8384, available legacy version 8389
    2013-06-27T20:44:05.813Z| vcpu-0| Guest: toolbox: Version: build-515842
    ...
    2013-06-28T20:38:16.923Z| vcpu-0| Ethernet0 MAC Address: 00:50:56:bf:73:51
    2013-06-28T20:38:16.927Z| vcpu-1| Ethernet2 MAC Address: 00:50:56:bf:73:53
    2013-06-28T20:39:16.930Z| vcpu-0| Guest: vfile: vf-AUDIT: VFileAuditSvmConnectivity : Lost connectivity to SVM, irpStatus: 0xc0000001 ## disconnect SecureVM
    2013-06-28T20:41:06.185Z| vmx| GuestRpcSendTimedOut: message to toolbox timed out.
    2013-06-28T20:41:06.186Z| vmx| Vix: [4304191 guestCommands.c:2194]: Error VIX_E_TOOLS_NOT_RUNNING in VMAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest
    2013-06-28T20:48:28.341Z| mks| MKS disabling SVGA
    2013-06-28T20:48:34.346Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 30 '
    2013-06-28T20:48:43.349Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 35 '

    This issue is resolved in this release.
  • Virtual machine becomes unresponsive due to a signal 11 error while executing SVGA code
    Virtual machine becomes unresponsive due to a signal 11 error, while executing SVGA code in svga2_map_surface.

    This issue is resolved in this release.
  • When ESXi host reports a disk full message the image utility function fails to clear the temp files
    After the ESXi host encounters a storage issue, such as disk full. The image utility function might fail to clear the tempFileName files from the vCloud Director.

    This issue is resolved in this release.
  • Hostd might stop responding and generates hostd-worker dump
    The ESXi 5.1 host might generate hostd-worker dump after you detach the software iSCSI disk, which is connected with vmknic on vDS. This issue occurs when you attempt to retrieve the latest information on the host.

    This issue is resolved in this release.
  • vSphere replication might fail after an upgrade from ESXi 5.1.x to 5.5 when vSphere Replication traffic checkbox is selected under Networking option using vSphere Web Client on ESXi 5.1.x
    You might be unable to replicate a virtual machine after you upgrade to ESXi 5.5 from ESXi 5.1.x. This issue occurs when vSphere Replication traffic checkbox is selected under Networking option using vSphere Web Client on ESXi 5.1.x.
    Error messages similar to the following are written to vmkernel.log file:

    2013-10-16T15:42:48.169Z cpu5:69024)WARNING: Hbr: 549: Connection failed to 10.1.253.51 (groupID=GID-46415ddc-2aef-4e9f-a173-49cc80854682): Timeout
    2013-10-16T15:42:48.169Z cpu5:69024)WARNING: Hbr: 4521: Failed to establish connection to [10.1.253.51]:31031(groupID=GID-46415ddc-2aef-4e9f-a173-49cc80854682): Timeout


    When you select virtual machine Summary tab, error messages similar to the following might be displayed:
    No Connection to VR server: Not responding

    Attempts to start synchronization might also fail with error message similar to the following:
    An ongoing synchronization task already exists

    The Tasks & Events tab might display the state of the virtual machine as Invalid.

    This issue is resolved in this release.
  • ESXi host might lose connection from vCenter Server when Storage vMotion is performed on a virtual machine undergoing replication
    When a virtual machine is replicated and you perform storage vMotion on the virtual machine, the hostd service might stop responding. As a result, ESXi host might lose connection from vCenter Server.
    The error messages similar to the following might be written to the hostd log files:

    2013-08-28T14:23:10.985Z [FFDF8D20 info 'TagExtractor'] 9: Rule type=[N5Hostd6Common31MethodNameBasedTagExtractorRuleE:0x4adddd0], id=rule[VMThrottledOpRule], tag=IsVMThrottledOp, regex=vim\.VirtualMachine\.(reconfigure|removeAllShapshots)|vim\.ManagedEntity\.destroy|vim\.Folder\.createVm|vim\.host\.LowLevelProvisioningManager\.(createVM|reconfigVM|consolidateDisks)|vim\.vm\.Snapshot\.remove - Identifies Virtual Machine operations that need additional throttling2013-08-28T14:23:10.988Z [FFDF8D20 info 'Default'] hostd-9055-1021289.txt time=2013-08-28 14:12:05.000--> Crash Report build=1021289--> Non-signal terminationBacktrace:--> Backtrace[0] 0x6897fb78 eip 0x1a231b70--> Backtrace[1] 0x6897fbb8 eip 0x1a2320f9

    This issue occurs if there is a configuration issue during virtual machine replication.

    This issue is resolved in this release.
  • Unable to create virtual machines on remotely mounted vSphere Storage Appliance datastore
    An ESXi host creating virtual machines on a remotely mounted vSphere Storage Appliance (VSA) datastore might stop responding. This is due to the VSA Manager plugin not handling network errors correctly.
    This issue occurs due to communication errors and the underlying function returning NULL pointer to the VSA Manager plugin.

    This issue is resolved in this release.
  • During target resets, lsilogic of a virtual machine waits for commands from all targets
    When the lsilogic virtual adapter performs a target reset, it waits for commands in flight for all targets on the adapter. This causes the target reset to block the virtual machine for more time than required.

    This issue is resolved in this release.

Networking

  • Multiple ESXi 5.1 hosts might stop responding intermittently when NetFlow monitoring is enabled on a distributed port group
    If NetFlow monitoring is enabled on a distributed port group, the Internet Protocol Flow Information Export (IPFIX) capability is used to monitor switch traffic. A race condition might occur in the IPFIX filter function when records with the same key co-exist in the hashtable, causing ESXi hosts to stop responding with a backtrace similar to the following:

    cpu8:42450)Panic: 766: Panic from another CPU (cpu 8, world 42450): ip=0x41801d47b266:
    #GP Exception 13 in world 42450:vmm0:Datacen @ 0x41801d4b7aaf
    cpu8:42450)Backtrace for current CPU #8, worldID=42450, ebp=0x41221749b390
    cpu8:42450)0x41221749b390:[0x41801d4b7aaf]vmk_SPLock@vmkernel#nover+0x12 stack: 0x41221749b3f0, 0xe00000000000
    cpu8:42450)0x41221749b4a0:[0x41801db01409]IpfixFilterPacket@ # +0x7e8 stack: 0x4100102205c0, 0x1, 0x
    cpu8:42450)0x41221749b4e0:[0x41801db01f36]IpfixFilter@ # +0x41 stack: 0x41801db01458, 0x4100101a2e58


    This issue is resolved in this release.
  • VMXNET 3 adapter might fail to load in Windows Server 2012 with 64-way virtual CPU (VCPU)
    VMXNET 3 adapter might fail to load in Windows Server 2012 with 64-way virtual CPU (VCPU) after reboot.

    This issue is resolved in this release.

  • The tcpdump-uw utility can only capture packets smaller than 8138 bytes
    The tcpdump-uw frame capture utility bundled with ESXi can only capture packets smaller than 8138 bytes. This issue occurs due to a socket buffer size being set to 8KB in VMware's implementation of tcpdump-uw. The socket buffer is set to 8192 bytes and approximately 54 bytes is needed for control data, making 8138 bytes the maximum that can be captured.

    The default buffer size is increased to 64KB to resolve the issue.
  • Management traffic configured on non Vmk0 network interface defaults to Vmk0 after upgrading from ESXi 5.0 to ESXi 5.1
    If a non Vmk0 vmknic is used for management traffic on ESXi 5.0 and it is upgraded to ESXi 5.1, the Management Traffic defaults to Vmk0. This is incorrect.

    This issue is resolved in this release.
  • Network packets drop is incorrectly reported in esxtop between two virtual machines on the same ESXi host and vSwitch
    When two virtual machines are configured with e1000 driver on the same vSwitch on a host, the network traffic between the two virtual machines might report significant packet drop in esxtop. This happens because during reporting there is no accounting for split packets when you enable TSO from guest.

    This issue is resolved in this release.
  • Linux commands, ip link or ip addr, might display the link state for VMXNET3 adapters as Unknown instead of Up
    When you create VMXNET3 adapters on the guest operating system, the Linux command, ip link or ip addr might display the link state as Unknown instead of Up.

    This issue is resolved in this release.
  • Virtual machines with Solaris 10 guest operating system and VMXNET3 drivers display overfragmented log messages on the console
    When you install VMware Tools on Solaris 10 virtual machine and create a VMXNET3 device on the guest operating system, log messages similar to the following are displayed on the virtual machine console:

    Apr 3 22:44:54 daxa020z last message repeated 274 times
    Apr 3 22:45:00 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    Apr 3 22:51:35 daxa020z last message repeated 399 times
    Apr 3 22:51:40 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)

    This issue is resolved in this release.
  • Obtaining the permanent MAC address for a VMXNET3 NIC might fail
    When you use the ETHTOOL_GPERMADDR ioctl to obtain the permanent MAC address for a VMXNET3 NIC, if the Linux kernel version is between 2.6.13 and 2.6.23, no results are obtained. If the Linux kernel version is above 2.6.23, the MAC address returned contains all zeros.

    This issue is resolved in this release.
  • ESXi 5.x host with virtual machines using an E1000 or E1000e virtual adapter fails with a purple diagnostic screen
    ESXi host experiences a purple diagnostic screen with errors for E1000PollRxRing and E1000DevRx when the rxRing buffer fills up and the max Rx ring is set to more than 2. The next Rx packet received that is handled by the second ring is NULL, causing a processing error. The purple diagnostic screen or backtrace contains entries similar to:

    @BlueScreen: #PF Exception 14 in world 63406:vmast.63405 IP 0x41801cd9c266 addr 0x0
    PTEs:0x8442d5027;0x383f35027;0x0;
    Code start: 0x41801cc00000 VMK uptime: 1:08:27:56.829
    0x41229eb9b590:[0x41801cd9c266]E1000PollRxRing@vmkernel#nover+0xdb9 stack: 0x410015264580
    0x41229eb9b600:[0x41801cd9fc73]E1000DevRx@vmkernel#nover+0x18a stack: 0x41229eb9b630
    0x41229eb9b6a0:[0x41801cd3ced0]IOChain_Resume@vmkernel#nover+0x247 stack: 0x41229eb9b6e0
    0x41229eb9b6f0:[0x41801cd2c0e4]PortOutput@vmkernel#nover+0xe3 stack: 0x410012375940
    0x41229eb9b750:[0x41801d1e476f]EtherswitchForwardLeafPortsQuick@ # +0xd6 stack: 0x31200f9
    0x41229eb9b950:[0x41801d1e5fd8]EtherswitchPortDispatch@ # +0x13bb stack: 0x412200000015
    0x41229eb9b9c0:[0x41801cd2b2c7]Port_InputResume@vmkernel#nover+0x146 stack: 0x412445c34cc0
    0x41229eb9ba10:[0x41801cd2ca42]Port_Input_Committed@vmkernel#nover+0x29 stack: 0x41001203aa01
    0x41229eb9ba70:[0x41801cd99a05]E1000DevAsyncTx@vmkernel#nover+0x190 stack: 0x41229eb9bab0
    0x41229eb9bae0:[0x41801cd51813]NetWorldletPerVMCB@vmkernel#nover+0xae stack: 0x2
    0x41229eb9bc60:[0x41801cd0b21b]WorldletProcessQueue@vmkernel#nover+0x486 stack: 0x41229eb9bd10
    0x41229eb9bca0:[0x41801cd0b895]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x10041229eb9bd20
    0x41229eb9bd20:[0x41801cc2083a]BH_Check@vmkernel#nover+0x185 stack: 0x41229eb9be20
    0x41229eb9be20:[0x41801cdbc9bc]CpuSchedIdleLoopInt@vmkernel#nover+0x13b stack: 0x29eb9bfa0
    0x41229eb9bf10:[0x41801cdc4c1f]CpuSchedDispatch@vmkernel#nover+0xabe stack: 0x0
    0x41229eb9bf80:[0x41801cdc5f4f]CpuSchedWait@vmkernel#nover+0x242 stack: 0x412200000000
    0x41229eb9bfa0:[0x41801cdc659e]CpuSched_Wait@vmkernel#nover+0x1d stack: 0x41229eb9bff0
    0x41229eb9bff0:[0x41801ccb1a3a]VmAssistantProcessTask@vmkernel#nover+0x445 stack: 0x0
    0x41229eb9bff8:[0x0] stack: 0x0

    This issue is resolved in this release.
  • Virtual machines with e1000 NIC might fail when placed in suspended mode
    Virtual machine might fail and display error messages in the vmware.log file similar to the following when the guest operating system with e1000 NIC driver is placed in suspended mode.

    2013-08-02T05:28:48Z[+11.453]| vcpu-1| I120: Msg_Post: Error
    2013-08-02T05:28:48Z[+11.453]| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1)
    2013-08-02T05:28:48Z[+11.453]| vcpu-1| I120+ Unexpected signal: 11.


    This issue occurs for the virtual machine that uses ip aliasing and the number of IP addresses exceed 10.

    This issue is resolved in this release.
  • IP address displayed on DCUI changes on reset when the management traffic is enabled on multiple VMkernel ports
    Whenever you reset a management network where the management traffic is enabled on multiple VMkernel ports, the IP address displayed on the Direct Console User Interface (DCUI) changes.

    This issue is resolved in this release.
  • ESXi host displays a purple diagnostic screen with a PF Exception 14 error
    ESXi hosts with DvFilter module might display a purple diagnostic screen. A backtrace similar to the following is displayed:

    2013-07-18T06:41:39.699Z cpu12:10669)0x412266b5bbe8:[0x41800d50b532]DVFilterDispatchMessage@com.vmware.vmkapi#v2_1_0_0+0x92d stack: 0x10
    2013-07-18T06:41:39.700Z cpu12:10669)0x412266b5bc68:[0x41800d505521]DVFilterCommBHDispatch@com.vmware.vmkapi#v2_1_0_0+0x394 stack: 0x100
    2013-07-18T06:41:39.700Z cpu12:10669)0x412266b5bce8:[0x41800cc2083a]BH_Check@vmkernel#nover+0x185 stack: 0x412266b5bde8, 0x412266b5bd88,

    This issue is resolved in this release.
  • Unused vSphere Distributed Switch (VDS) ports are not cleared from the .dvsData directory on the datastores
    During vMotion of a virtual machine which has a vNIC connected to VDS, port files from the vMotion source host is not cleared in .dvsData directory even after a while.

    This issue is resolved in this release.
  • Intel e1000e network interface driver might stop responding on received (RX) traffic.
    Intel e1000e network interface driver might stop responding on received (RX) traffic.

    This issue is resolved in this release.

  • ESXi host might fail with a purple diagnostic screen due to a conflict between two DVFilter processes
    If two DVF filter processes attempt to manage a single configuration variable at the same time, while one process frees the filter configuration and the other process attempts to lock it, this might lead to an ESXi host failure.

    This issue is resolved in this release.
  • The return value of net.throughput.usage in vCenter performance chart and vmkernel are contradictory
    In vCenter performance chart, the net.throughput.usage related value is in Kilobytes, but the same value is returned in bytes in the vmkernel. This leads to incorrect representation of values in the vCenter performance chart.

    This issue is resolved in this release.
  • ESXi hosts might stop responding when the L2Echo function is unable to handle network traffic
    When the Network Healthcheck feature is enabled, the L2Echo function might not be able to handle high network traffic and the ESXi hosts might stop responding with a purple diagnostic screen and a backtrace similar to the following:

    cpu4:8196)@BlueScreen: PCPU 1: no heartbeat (2/2 IPIs received)
    cpu4:8196)Code start: 0x418024600000 VMK uptime: 44:20:54:02.516
    cpu4:8196)Saved backtrace from: pcpu 1 Heartbeat NMI
    cpu4:8196)0x41220781b480:[0x41802468ded2]SP_WaitLockIRQ@vmkernel#nover+0x199 stack: 0x3b
    cpu4:8196)0x41220781b4a0:[0x4180247f0253]Sched_TreeLockMemAdmit@vmkernel#nover+0x5e stack: 0x20
    cpu4:8196)0x41220781b4c0:[0x4180247d0100]MemSched_ConsumeManagedKernelMemory@vmkernel#nover+0x1b stack: 0x0
    cpu4:8196)0x41220781b500:[0x418024806ac5]SchedKmem_Alloc@vmkernel#nover+0x40 stack: 0x41220781b690
    ...
    cpu4:8196)0x41220781bbb0:[0x4180247a0b13]vmk_PortOutput@vmkernel#nover+0x4a stack: 0x100
    cpu4:8196)0x41220781bc20:[0x418024c65fb2]L2EchoSendPkt@com.vmware.net.healthchk#1.0.0.0+0x85 stack: 0x4100000
    cpu4:8196)0x41220781bcf0:[0x418024c6648e]L2EchoSendPort@com.vmware.net.healthchk#1.0.0.0+0x4b1 stack: 0x0
    cpu4:8196)0x41220781bfa0:[0x418024c685d9]L2EchoRxWorldFn@com.vmware.net.healthchk#1.0.0.0+0x7f8 stack: 0x4122
    cpu4:8196)0x41220781bff0:[0x4180246b6c8f]vmkWorldFunc@vmkernel#nover+0x52 stack: 0x0


    This issue is resolved in this release.
  • Provisioning and customizing a virtual machine might result in loss of network connection
    When you provision and customize a virtual machine from a template on a vDS with Ephemeral Ports, the virtual machine might lose connection from the network.
    The error messages similar to the following might be written to the log files:

    2013-08-05T06:33:33.990Z| vcpu-1| VMXNET3 user: Ethernet1 Driver Info: version = 16847360 gosBits = 2 gosType = 1, gosVer = 0, gosMisc = 02013-08-05T06:33:35.679Z| vmx| Msg_Post: Error
    2013-08-05T06:33:35.679Z| vmx| [msg.mac.cantGetPortID] Unable to get dvs.portId for ethernet0
    2013-08-05T06:33:35.679Z| vmx| [msg.mac.cantGetNetworkName] Unable to get networkName or devName for ethernet0
    2013-08-05T06:33:35.679Z| vmx| [msg.device.badconnect] Failed to connect virtual device Ethernet0.

    This issue is resolved in this release.
  • VMXNET3 resets frequently when Receive Side Scaling (RSS) is enabled in a virtual machine
    When Receive Side Scaling (RSS) is enabled on a virtual machine, the VMXNET3 network driver resets frequently causing virtual machine to lose network connectivity for a brief period of time.

    This issue is resolved in this release. The VMXNET3 network driver is updated in this release.

  • Virtual machines lose network connectivity while performing snapshot commit operation
    Virtual machines lose network connectivity and do not respond during snapshot consolidations after a virtual machine backup. The virtual machines are reported as not busy during this period.

    This issue is resolved in this release.

  • USB controllers cannot be configured to be DirectPath I/O passthrough
    If you configure a USB host controller device to be DirectPath I/O passthrough and reboot the host, the settings do not persist.

    This issue is resolved in this release. However, do not configure USB controllers as passthrough if you boot ESXi hosts from USB devices such as an SD card.

Security

  • Update to OpenSSL library addresses multiple security issues
    The ESXi userworld OpenSSL library is updated to version openssl-0.9.8y to resolve multiple security issues.

    The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2013-0169 and CVE-2013-0166.
  • Update to libxml2 library addresses multiple security issues
    The ESXi userworld libxml2 library has been updated to resolve a security issue.

    The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2013-0338 to this issue.
  • NULL pointer dereference while handling the Network File Copy (NFC) traffic
    VMware ESXi and ESX contain a NULL pointer dereference in the handling of the Network File Copy (NFC) traffic. To exploit this vulnerability, an attacker must intercept and modify the NFC traffic between ESXi/ESX and the client. Exploitation of the issue might lead to a Denial of Service.

    The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2014-1207 to this issue.
  • EHCI does not validate port fields correctly
    Due to a flaw in the handling of invalid ports, it is possible to cause the VMX process to fail. This vulnerability may allow a guest user to crash the VMX process resulting in a partial denial of service on the host.

    The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2014-1208 to this issue.

Server Configuration

  • NetApp has requested an update to the SATP claim rule which prevents the iSCSI from entering an unresponsive state
    NetApp has requested an update to the SATP claim rule which prevents the reservation conflict for a Logical Unit Number (LUN). The updated SATP claim rule uses the reset option to clear the reservation from the LUN and allows other users to set the reservation option.

    This issue is resolved in this release.
  • When you boot from a Storage Area Network it might take longer to discover the boot device depending on the network bandwidth
    When you boot from a SAN and the boot device discovery process takes more time to complete, ESXi host /bootbank will point to /tmp. With this release we have provided bootDeviceRescanTimeout parameter to ESXi command line which can be passed before the boot process to configure the timeout value to resolves the issue.

    This issue is resolved in this release.
  • Attempts to apply a host profile might fail while removing multiple NFS datastores
    When you attempt to remove multiple NFS datastores using the Host Profile option, an error occurs because there might be a datastore that has already been deleted.

    This issue is resolved in this release.
  • vSwitch Failback and Failover Order settings are not copied to the host when you apply host profile
    When you attach a host profile to an host, vSwitch properties such as Failback and Failover Order extracted from a reference host is not applied to the host.

    This issue is resolved in this release.
  • ESXi host reports incorrect login time for ha-eventmgr in hostd.log file
    The ESXi host might incorrectly display the last login time for the root as 1970, this information is displayed for ha-eventmgr on the ESXi hosts’ Web client. In this release the login time is calculated using the system time which solves the issue.

    This issue is resolved in this release.
  • Unable to find state.tgz backup file on boot device while attempting to upgrade ESXi host
    When you attempt to upgrade ESXi host using an ISO image, you might be unable to find the state.tgz backup file on the boot device. This issue occurs if the state.tgz backup file is not updated because you did not shut down your machine properly before upgrading. As a result, No such a file exception error is displayed while resetting ESXi license.
  • This issue is resolved in this release.

  • ESXi host fails with a host profile error when changing the network failover setting to beacon probing
    While applying the host profile to an ESXi host, if you attempt to change the network fail over detection to beacon probing, the ESXi host fails with an error message similar to the following:

    Associated host profile contains NIC failure criteria settings that cannot be applied to the host

    This issue is resolved in this release.
  • The bandwidthCap option of an ESXi host might not work on guest operating system
    On an ESXi host when bandwidthCap and throughputCap are set at the same time, the I/O throttling option might not work on virtual machines. This happens because of incorrect logical comparison while setting the throttle option in scsi scheduler.

    This issue is resolved in this release.
  • When you query the ESXi host through SNMP the host reports incorrect CPU load average value
    When you perform SNMP query to the ESXi host for CPU load average, instead of calculating the hrProcessorLoad for the past minute the hrProcessorLoad calculates the CPU load for the entire life time. This results in the host reporting incorrect CPU load average value.

    This issue is resolved in this release.
  • ESXi host displays incorrect values for the resourceCpuAllocMax and resourceMemAllocMax system counter
    When you attempt to retrieve the value for the resourceCpuAllocMax and resourceMemAllocMax system counters against the host system, the ESXi host returns incorrect values. This issue is observed on a vSphere Client connected to vCenter Server.

    This issue is resolved in this release
  • The ESXi host profile reports a compliance failure with Option Annotaitons.WelcomeMessage does not match the specified Criteria error message
    Every time you add a text in the Annotations.WelcomeMessage and create an ESXi host profile and apply the same host profile to other hosts, then the other host reports an error message similar to the following:

    Option Annotaitons.WelcomeMessage does not match the specified Criteria

    This issue is resolved in this release.
  • Multiple ESXi servers might stop responding in the vCenter Server
    When high volume of parallel HTTP GET /folder URL requests are sent to hostd, the hostd service fails. This stops from adding the host back to the vCenter Server. An error message similar to the following might be displayed:

    Unable to access the specified host, either it doesn't exist, the server software is not responding, or there is a network problem.

    This issue is resolved in this release.

  • Unable to add permissions from vSphere Client to Active Directory users or groups on an ESXi host joined to an Active Directory (AD) domain
    You might not be able to add permissions to AD users or groups because the domain name is not available for selection in the Domain drop-down menu.

    This issue is resolved in this release.
  • SNMP traps not received on hosts where SNMP is enabled and third-party CIM providers are installed on the server
    When the monitored hardware status is changed on an ESXi host that has SNMP enabled and third Party CIM Providers installed on the server, you might not receive SNMP trap. Messages similar to the following are logged in the syslog file:

    2013-07-11T05:24:39Z snmpd: to_sr_type: unable to convert varbind type '71'
    2013-07-11T05:24:39Z snmpd: convert_value: unknown SR type value 0
    2013-07-11T05:24:39Z snmpd: parse_varbind: invalid varbind with type 0 and value: '2'
    2013-07-11T05:24:39Z snmpd: forward_notifications: parse file '/var/spool/snmp/1373520279_6_1_3582.trp' failed, ignored

    This issue is resolved in this release.
  • Cluster wide storage rescan from vCenter Server causes ESXi hosts and virtual machines to become unresponsive
    When you perform certain operations that directly or indirectly involve Virtual Machine File System (VMFS), usually in an ESXi cluster environment sharing a large number of VMFS datastores, you might encounter the following problems:
    • ESXi host stops responding intermittently
    • ESXi host gets disconnected from the vCenter Server
    • Virtual machine stops responding intermittently
    • The virtual machines that are part of Microsoft Cluster Service (MSCS) stops responding, resulting in failover
    • Host communication errors occur during Site Recovery Manager (SRM) data recovery and failover tests

  • This issue is resolved in this release.
  • Unable to get IPMI Sensor data
    When you periodically run exscli hardware ipmi sdr list command, the IPMI data repository might stop working.

    This issue is resolved in this release.

  • TCP, SSL remote logging does not restart automatically after a network interruption
    VMware ESXi 5.x host configured with TCP/SSL remote syslog stops sending syslogs to remote log server when the network connection to the remote log server is interrupted and restored.

    This issue is resolved by adding a Default Network Retry Timeout and the host retries to send syslog after Default Network Retry Timeout. The default value of Default Network Retry Timeout is 180 seconds. The command esxcli system syslog config set --default-timeout= can be used to change the default value.

    This issue is resolved in this release.
  • ESXi host stops responding experiencing a purple diagnostic screen with a PCPU XX didn't have a heartbeat error
    The ESXi host might become unresponsive during vMotion with the trace as displayed below:
     
    2013-07-18T17:55:06.693Z cpu24:694725)0x4122e7147330:[0x418039b5d12e]Migrate_NiceAllocPage@esx#nover+0x75 stack: 0x4122e7147350
    2013-07-18T17:55:06.694Z cpu24:694725)0x4122e71473d0:[0x418039b5f673]Migrate_HeapCreate@esx#nover+0x1ba stack: 0x4122e714742c
    2013-07-18T17:55:06.694Z cpu24:694725)0x4122e7147460:[0x418039b5a7ef]MigrateInfo_Alloc@esx#nover+0x156 stack: 0x4122e71474f0
    2013-07-18T17:55:06.695Z cpu24:694725)0x4122e7147560:[0x418039b5df17]Migrate_InitMigration@esx#nover+0x1c2 stack: 0xe845962100000001
    ...
    2013-07-18T17:55:07.714Z cpu25:694288)WARNING: Heartbeat: 646: PCPU 27 didn't have a heartbeat for 7 seconds; *may* be locked up.
    2013-07-18T17:55:07.714Z cpu27:694729)ALERT: NMI: 1944: NMI IPI received. Was eip(base):ebp:cs


    This occurs while running vMotion on a host under memory overload.

    This issue is resolved in this release.
  • ESXi host fails to to get information related to maximum LBA count and maximum unmap descriptor count when you execute unmap command
    When you execute the unmap command, ESXi host retrieves maximum LBA count and maximum unmap descriptor count when disk is opened and caches it. The host uses this information to validate requests by virtual SCSI. Earlier the host failed to retrieve the required information.

    This issue is resolved in this release.
  • ESXi server fails to boot when you enable TXT function in server uEFI BIOS
    If you enable TPM/TXT in system uEFI BIOS of an ESXi host, then both Tboot and ESXi host might fail to boot. This issue is observed on IBM 3650 M4 server.

    This issue is resolved in this release.
  • ESXi host fails with a purple diagnostic screen when handling SCSI mid-layer frame in SCSIPathTimeoutHandlerFn
    If the timer fires even before SCSI mid-layer frame gets initialized with vmkCmd option in the SCSI function, then ESXi host might fail with a purple diagnostic screen and an error message similar to the following might be displayed:

    @BlueScreen: #PF Exception 14 in world 619851:PathTaskmgmt IP 0x418022c898f6 addr 0x48
    Code start: 0x418022a00000 VMK uptime: 9:08:16:00.066
    0x4122552dbfb0:[0x418022c898f6]SCSIPathTimeoutHandlerFn@vmkernel#nover+0x195 stack:
    0x4122552e7000 0x4122552dbff0:[0x418022c944dd]SCSITaskMgmtWorldFunc@vmkernel#nover+0xf0 stack: 0x0


    This issue is resolved in this release.
  • ESXi host does not report configuration issues if core dump partition and core dump collector services are not configured
    If an ESXi host is not configured with a core dump partition and neither configured to direct core dumps to a dump collector server, we might lose important troubleshooting information in case of host panic. With this release we have included a check for this configuration in host agent and hence host Summary tab and Events tab will show the issue if core dump partition or dump collector service is not configured.

    This issue is resolved in this release.
  • Applying Host Profile with preferred path settings fails on the destination host with Invalid Path Value error
    Configure Host1 with Path Selection Policy (PSP) set as fixed, and configure a preferred path, then extract profile from Host1 and apply the profile to Host2. During the initial check of the Host2 profile the Host Profile Plugin module might encounter Invalid Path Value error and report the invalid path value.

    This issue is resolved in this release.
  • Host compliance check fails with an error related to extracting indication configuration
    When there is invalid CIM subscription in the system and you perform a host profile compliance check against a host, an error message similar to the following might be displayed:

    Error extracting indication configuration: (6, u'The requested object could not be found')

    You cannot apply the host profile on the host.

    This issue is resolved in this release. You can apply host profiles even when there is a invalid indication in the host profile.

  • VMkernel fails when virtual machine monitor returns an invalid machine page number
    When virtual machine monitor (VMM) passes a VPN value to read a page, VMkernel might fail to find a valid machine page number for that VPN value. This results in the host failing with a purple diagnostic screen. This issue occurs when VMM sends a bad VPN while performing a monitor core dump during a VMM failure.

    This issue is resolved in this release.

  • When you upgrade ESXi 5.0.x to ESXi 5.1.x the host loses the NAS datastores and other configurations
    When you upgrade ESXi 5.0.x to ESXi 5.1.x using vCenter Update Manager, the ESXi host loses the NAS datastore entries containing the string Symantec. In this release, the script is modified to remove unnecessary entries from the configuration files during upgrade, which resolves this issue.

    This issue is resolved in this release.

Storage

  • Request Sense command sent from a guest operating system does not return any data
    When a SCSI Request Sense command is sent to Raw Device Mapping (RDM) in Physical Mode from a guest operating system, sometimes the returned sense data is NULL (zeroed). The issue only occurs when the command is sent from the guest operating system.

    This issue is resolved in this release.
  • Cloning and cold migration of virtual machines with large VMDK and snapshot files might fail
    You might be unable to clone and perform cold migration of virtual machines with large virtual machine disk (VMDK) and snapshot files to other datastores. This issue occurs when the vpxa process exceeds the limit of memory allocation during cold migration. As a result, the ESXi host loses the connection from the vCenter Server and the migration fails.

    This issue is resolved in this release.
  • False Device Busy (D:0x8) status messages might be displayed in the VMkernel log files when vmklinux incorrectly sets the device status
    When vmklinux incorrectly sets the device status, false Device Busy (D:0x8) status messages similar to the following are displayed in VMkernel log files:

    2013-04-04T17:56:47.668Z cpu0:4012)ScsiDeviceIO: SCSICompleteDeviceCommand:2311: Cmd(0x412441541f80) 0x16, CmdSN 0x1c9f from world 0 to dev "naa.600601601fb12d00565065c6b381e211" failed H:0x0 D:0x8 P:0x0 Possible sense data: 0x0 0x0 0x0

    This generates false alarms, as the storage array does not send any Device Busy status message for SCSI commands.
    This issue is resolved in this release by correctly pointing to Host Bus Busy (H:0x2) status messages for issues in the device drivers similar to the following:

    2013-04-04T13:16:27.300Z cpu12:4008)ScsiDeviceIO: SCSICompleteDeviceCommand:2311: Cmd(0x4124819c2f00) 0x2a, CmdSN 0xfffffa80043a2350 from world 4697 to dev "naa.600601601fb12d00565065c6b381e211" failed H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0

    This issue is resolved in this release.
  • vCenter Server or vSphere Client might get disconnected from the ESXi host during VMFS datastore creation
    vCenter Server or vSphere Client might get disconnected from the ESXi host during VMFS datastore creation. This issue occurs when hostd fails with the error message similar to the following in the hostd log file:

    Panic: Assert Failed: \"matchingPart != __null\".

    The hostd fails during VMFS datastore creation on disks with certain partition configuration that requires partition alignment.

    This issue is resolved in this release.
  • Provisioned space value for NFS datastore incorrectly calculated and result in false alarms
    Under certain conditions, provisioned space value for NFS datastore might be incorrectly calculated and false alarms might be generated.

    This issue is resolved in this release.
  • Unable to bring data stores back online after a Permanent Device Loss
    After a Permanent Device Loss (PDL), you are unable to bring data stores back online due to some open file handles on the volume.

    This issue is resolved in this release.
  • Loading nfsclient module during ESXi boot process causes load failure of other modules
    During the ESXi boot process, loading the nfsclient module might hold lock on the esx.conf file for a long time if there is a delay in the host name resolution for Network File System (NFS) mount points. This might cause failure of other module loads such as migrate, ipmi, or others.

    This issue is resolved in this release.
  • Unable to access the VMFS datastore or some files
    You might find the Virtual Machine File System (VMFS) datastore missing from the vCenter Server's Datastore tab or an event similar to the following displayed in the Events tab:

    XXX esx.problem.vmfs.lock.corruptondisk.v2 XXX or At least one corrupt on-disk lock was detected on volume {1} ({2}). Other regions of the volume might be damaged too.

    The following log message is displayed in the VMkernel log:

    [lockAddr 36149248] Invalid state: Owner 00000000-00000000-0000-000000000000 mode 0 numHolders 0 gblNumHolders 4294967295ESC[7m2013-05-12T19:49:11.617Z cpu16:372715)WARNING: DLX: 908: Volume 4e15b3f1-d166c8f8-9bbd-14feb5c781cf ("XXXXXXXXX") might be damaged on the disk. Corrupt lock detected at offset 2279800: [type 10c00001 offset 36149248 v 6231, hb offset 372ESC[0$

    You might also see the following message logged in the vmkernel.log file :

    2013-07-24T05:00:43.171Z cpu13:11547)WARNING: Vol3: ValidateFS:2267: XXXXXX/51c27b20-4974c2d8-edad-b8ac6f8710c7: Non-zero generation of VMFS3 volume: 1

    This issue is resolved in this release.
  • ESXi 5.1 hosts might fail with a purple diagnostic screen and error messages related to the DevFSFileClose function
    When multiple threads try to close the same device at the same time, ESXi 5.1 hosts might fail with a purple diagnostic screen and a backtrace similar to the following:

    cpu1:16423)@BlueScreen: #PF Exception 14 in world 16423:helper1-0 IP 0x41801ac50e3e addr 0x18PTEs:0x0;
    cpu1:16423)Code start: 0x41801aa00000 VMK uptime: 0:09:28:51.434
    cpu1:16423)0x4122009dbd70:[0x41801ac50e3e]FDS_CloseDevice@vmkernel#nover+0x9 stack: 0x4122009dbdd0
    cpu1:16423)0x4122009dbdd0:[0x41801ac497b4]DevFSFileClose@vmkernel#nover+0xf7 stack: 0x41000ff3ca98
    cpu1:16423)0x4122009dbe20:[0x41801ac2f701]FSS2CloseFile@vmkernel#nover+0x130 stack: 0x4122009dbe80
    cpu1:16423)0x4122009dbe50:[0x41801ac2f829]FSS2_CloseFile@vmkernel#nover+0xe0 stack: 0x41000fe9a5f0
    cpu1:16423)0x4122009dbe80:[0x41801ac2f89e]FSS_CloseFile@vmkernel#nover+0x31 stack: 0x1
    cpu1:16423)0x4122009dbec0:[0x41801b22d148]CBT_RemoveDev@ # +0x83 stack: 0x41000ff3ca60
    cpu1:16423)0x4122009dbef0:[0x41801ac51a24]FDS_RemoveDev@vmkernel#nover+0xdb stack: 0x4122009dbf60
    cpu1:16423)0x4122009dbf40:[0x41801ac4a188]DevFSUnlinkObj@vmkernel#nover+0xdf stack: 0x0
    cpu1:16423)0x4122009dbf60:[0x41801ac4a2ee]DevFSHelperUnlink@vmkernel#nover+0x51 stack: 0xfffffffffffffff1
    cpu1:16423)0x4122009dbff0:[0x41801aa48418]helpFunc@vmkernel#nover+0x517 stack: 0x0
    cpu1:16423)0x4122009dbff8:[0x0] stack: 0x0
    cpu1:16423)base fs=0x0 gs=0x418040400000 Kgs=0x0
    cpu1:16423)vmkernel 0x0 .data 0x0 .bss 0x0
    cpu1:16423)chardevs 0x41801ae70000 .data 0x417fc0000000 .bss 0x417fc00008a0

    This issue is resolved in this release.

  • Logical Unit Number reset fails in fc_fcp_resp function while handling FCP_RSP_INFO
    In a LUN RESET task with NetApp targets, it is observed that LUN RESET fails. The fc_fcp_resp() is not completing the LUN RESET task since fc_fcp_resp assumes that the FCP_RSP_INFO is 8 bytes with the 4 byte reserved field, however, in case of NetApp targets the FCP_RSP to LUN RESET only has 4 bytes of FCP_RSP_INFO. This leads to fc_fcp_resp error without completing the task. Reset the host to fix the issue.

    This issue is resolved in this release
  • ESXi user cannot disable Fibre Channel over Ethernet on ports which does not used for boot from SAN device
    In an ESXi host when you boot from a Fibre Channel over Ethernet Storage Area Network, you might not be able to disable the FCoE on any port which are not even used to present the FCoE boot LUN.

    This issue is resolved in this release.
  • Software iSCSI parameter changes are not logged in the syslog.log file
    Starting with this release, changes to the software iSCSI session and connection parameters are now logged in the syslog.log file and it includes previous and new parameter values.

    This issue is resolved in this release.
  • Virtual machines might stop responding during snapshot consolidation
    Attempts to consolidate snapshots on vCenter Server might fail with error message similar to the following:

    hierarchy is too deep

    This issue occurs when the virtual machine has 255 or more snapshots created by vSphere Replication.

    This issue is resolved in this release.
  • Attempts to take snapshots of virtual machines with shared virtual disks might fail when Oracle Clustureware is used
    When multi-writer option is used on shared virtual disks along with the Oracle Real Application Cluster (RAC) option of Oracle Clusterware software, attempts to take snapshots of virtual machines without their memory might fail, and the virtual machines might stop running. Log files might contain entries similar to the following:

    Resuming virtual disk scsi1:5 failed. The disk has been modified since a snapshot was taken or the virtual machine was suspended.

    This issue might be observed with other cluster management softwares as well.

    This issue is resolved in this release.

  • Host profile might not be correctly applied to ESXi hosts with AutoDeploy using stateless caching
    When you use Auto Deploy with stateless caching, the host profile might not be correctly applied to the ESXi host. As a result, the host does not become compliant when it joins vCenter Server.
    This issue occurs when there are approximately 30 or more VMFS datastores.
    This issue does not occur when you manually apply the host profile.

    This issue is resolved in this release.

Upgrade and Installation

  • Host remediation against bulletins that have only Reboot impact fails
    During the remediation process of a stand alone ESXi host against a patch baseline, which consists of bulletins that have only Reboot impact, Update Manager fails to power off or suspend the virtual machines that are on the host. As a result the host cannot enter maintenance mode, and the remediation cannot be completed.

    This issue is resolved in bulletins created in this release and later.
  • Stateless caching does not update a locally cached host profile
    If stateless caching is enabled on an ESXi 5.1 host and host profile is applied again on the cached image after any configuration changes, then the newly made host profile configurations are not applied.

    This issue is resolved in this release.

  • Virtual machine fails to install Solaris JDK on Solaris 10 operating system
    When you install Solaris 10 on a virtual machine and run the command smbios -t 4 to check the CPU version, the virtual machine returns a blank version, and if you attempt to install JDK 1.6, the installation fails.

    This issue is resolved in this release.

vCenter Server, vSphere Client, and vSphere Web Client

  • Customized performance chart does not provide the option of displaying the aggregate virtual disk stats for virtual machine objects
    When you use the virtual disk metric to view performance charts, you only have the option of viewing the virtual disk performance charts for the available virtual disk objects.

    This release allows you to view virtual disk performance charts for virtual machine objects as well. This is useful when you need to trigger alarms based on virtual disk usage by virtual machines.
  • The Summary tab might display incorrect values for provisioned space for Hosts with VAAI NAS
    When a virtual disk with Thick Provision Lazy zeroed format is created on an ESXi host with VAAI NAS, in the Datastores and Datastore Cluster view, the Provisioned space displayed on the Summary tab might be double of the provisioned storage set for the virtual disk.
    For example if the provisioned storage is 75GB, the provisioned space displayed might be around 150 GB.

    This issue is resolved in this release.

Virtual Machine Management

  • In a virtual machine the WPF application displays items incorrectly when the 3D software rendering option is enabled
    When you install a Windows Presentation Foundation (WPF) application on a virtual machine and enable the 3D software rendering option, the WPF application might have inconsistency while displaying some images.

    This issue is resolved in this release.
  • Guest operating system fails with bug check code PAGE_FAULT_IN_NONPAGED_AREA during auto-install of win2000 Server with 8 or more virtual CPUs
    When you install Windows 2000 Server on a virtual machine, the guest operating system fails with a blue diagnostic screen and a PAGE_FAULT_IN_NONPAGED_AREA error message. This issue is observed in Windows 2000 virtual machine with eight or more virtual CPUs.

    This issue is resolved in this release.

  • Attempts to export a virtual machine as OVF fails with a timeout error
    When you attempt to export a virtual machine in an Open Virtualization Format (OVF) if the virtual machine has large portion of empty blocks on the disk, for example 210GB or more, and uses an Ext 2 or an Ext 3 file system, the operation times out.

    This issue is resolved in this release.


  • The hot remove of a shared non persistent disk takes more time when the disk is attached(or shared) with another powered on virtual machine
    When you add shared non persistent read only disks to a virtual machine, the virtual machine might stop responding. This happens because the virtual machine opens the read only disks in exclusive mode.

    This issue is resolved in this release.

vMotion and Storage vMotion

  • Incremental backup might fail with FileFault error for QueryChangedDiskAreas after moving a VMDK to a different volume using vMotion for a CBT-enabled virtual machine
    On a Changed Block Training (CBT) enabled virtual machine, when you perform QueryChangedDiskAreas after moving a virtual machine disk
    (VMDK) to a different volume using Storage vMotion, as CBT information gets re-initialized without discarding all ChangeID references it might result in a FileFault error similar to the following:

    2012-09-04T11:56:17.846+02:00 [03616 info 'Default' opID=52dc4afb] [VpxLRO] -- ERROR task-internal-4118 -- vm-26512 --
    vim.VirtualMachine.queryChangedDiskAreas: vim.fault.FileFault:
    --> Result:
    --> (vim.fault.FileFault) {
    --> dynamicType = <unset>,
    --> faultCause = (vmodl.MethodFault) null, file =
    --> "/vmfs/volumes/4ff2b68a-8b657a8e-a151-3cd92b04ecdc/VM/VM.vmdk",
    --> msg = "Error caused by file
    /vmfs/volumes/4ff2b68a-8b657a8e-a151-3cd92b04ecdc/VM/VM.vmdk",
    --> }

    To resolve the issue, CBT tracking is deactivated and reactivated after moving a virtual machine disk (VMDK) to a different datastore using Storage vMotion, it must discard all changeId reference and take a full backup to utilize CBT for further incremental backup.

    This issue occurs when a library function incorrectly re-initializes the disk change tracking facility.

    This issue is resolved in this release.

VMware HA and Fault Tolerance

  • Attempts to enable a High Availability cluster might fail after a single host is placed in maintenance mode
    Attempts to enable a High Availability (HA) cluster might fail after a single host of the same HA cluster is placed in maintenance mode. This issue occurs when the value of the inode descriptor number is not set correctly in ESXi root file system (Visorfs), and as a result, the stat calls on those inodes fail.

    This issue is resolved in this release.

VMware Tools

  • VMware Tools installer will not install vmhgfs module when Virtual Machine Communication Interface (VMCI) and VMCI Sockets (VSOCK) are upstreamed after enabling vmhgfs installation
    If you attempt to install VMware Tools when VMCI and VSOCK are upstreamed, the installer will not install vmhgfs module when you enable this module installation. This issue is observed on Linux operating system with kernel version 3.9 or later.

    This issue is resolved in this release.
  • When VMCI & VSOCK are upstreamed, VMware Tools installer will not replace them any more
    If you run /etc/vmware-tools/service.sh restart command to check services when VMCI and VSOCK are upstreamed and VMware Tools are installed, the status of VMCI might be displayed as failed. This issue is observed on Linux operating system with kernel version 3.9 or later.

    This issue is resolved in this release.
  • Virtual machines with Windows operating system might display warning messages when you upgrade VMware Tools
    On an ESXi 5.1 host when you upgrade VMware Tools to version 9.0, virtual machines with Windows operating system might display a warning message similar to the following:

    Failed registration of app type 2 (Signals) from plugin unity

    This issue is resolved in this release.
  • open-vm-tools is uninstalled by Linux VMware Tools installer
    When a user runs the VMware Tools installer on vSphere in an OS that includes open-vm-tools, open-vm-tools is automatically uninstalled and VMware Tools is installed.

    This issue is resolved in this release.

  • Solaris 10 virtual machines become unresponsive when you install VMware Tools from ESXi 5.1
    If you install VMware Tools from ESXi 5.1 to a Solaris 10 virtual machine, then the virtual machine might become unresponsive and might display a message similar to the following:

    Wait for the CDE desktop to start

    This issue is resolved in this release.
  • Attempts to set up a filter rule that contains the drive letter for a volume with an unsupported file system might result in the failure of Windows Server 2003 or Windows XP virtual machine with a blue screen
    When you attempt to set up a filter rule that contains the drive letter for a volume with an unsupported file system, Windows Server 2003 or Windows XP virtual machine might fail with a blue screen and might display error messages similar to the following:

    Error code 1000007e, parameter1 c0000005, parameter2 baee5d3b, parameter3 baa69a64, parameter4 baa69760.
    ...
    Data:
    0000: 53 79 73 74 65 6d 20 45 System E
    0008: 72 72 6f 72 20 20 45 72 rror Er
    0010: 72 6f 72 20 63 6f 64 65 ror code
    0018: 20 31 30 30 30 30 30 37 10000070020: 65 20 20 50 61 72 61 6d e Param
    0028: 65 74 65 72 73 20 63 30 eters c
    00030: 30 30 30 30 30 35 2c 20 000005,
    0038: 62 61 65 65 35 64 33 62 baee5d3b
    0040: 2c 20 62 61 61 36 39 61 , baa69a
    0048: 36 34 2c 20 62 61 61 36 64, baa6
    0050: 39 37 36 30 9760

    This issue mostly occurs when the Q:\ drive letter created by Microsoft App-V solution is added in the filter rule.

    This issue is resolved in this release.
  • VMware Tools is updated to provide pre-built modules for SUSE Linux Enterprise 11 SP3, Oracle Linux 5.x with 2.6.39-200/300/400 kernels and Oracle Linux 6.x with 2.6.39-200/300/400 kernels
  • vmblock modules might fail to compile when you install VMware Tools on Linux kernel versions later than 3.5
    When you install VMware Tools on Linux kernel versions later than 3.5, vmblock modules might fail to compile and the ..make: *** [vmblock.ko] Error 2 error message is displayed.

    This issue is resolved in this release. The fix stops compilation of vmblock module on kernels 3.5 and later as support for FUSE is enabled from kernel 2.6.32 and later.
  • VMware Tools fails to start if the VMCI and VSOCK drivers are installed with the clobber option
    If you install VMware Tools with the --clobber-kernel-modules=vmci,vsock option, the VMware Tools service fails to start and an error message similar to the following is displayed:

    Creating a new initrd boot image for the kernel.
    update-initramfs: Generating /boot/initrd.img-3.9.0-rc2-custom
    vmware-tools-thinprint start/running
    initctl: Job failed to start
    Unable to start services for VMware Tools

    Execution aborted.


    This issue is resolved in this release. You can no longer install VMCI and VSOCK drivers after they are upstreamed with Linux kernel versions later than 3.9.
  • VMware Tools might stop running in Novell NetWare 6.5 virtual machines
    VMware Tools might stop running in Novell NetWare 6.5 virtual machines. This might cause high CPU utilization and DRS migration.

    This issue is resolved in this release.
  • Uninstalling VMware Tools on Window Server 2003
    When you attempt to uninstall VMware Tools on a Windows Server 2003, the virtual machine fails to uninstall VMware Tools and displays the Uninstallation is not successful error message.

    This issue is resolved in this release.

  • VMware config.pl fails to print reboot recommendation after VMXNET 3 and PVSCSI upgrade
    On any Linux guest operating system, when you install VMware tools and upgrade it to the latest version, the VMware Tools installation fails to print recommendations for reloading the VMXNET/VMXNET 3 and PVSCSI driver modules or reboot the virtual machine at the end of the installation.

    This issue is resolved in this release.
  • Guest operating system event viewer displays warning messages after you install VMware Tools
    After you install VMware Tools, if you attempt to do a RDP to a Windows virtual machine, some of the plugins might display a warning message in the Windows event log. The warning message indicates the failure to send remote procedure calls to the host.

    This issue is resolved in this release.

  • Memory leak in vmtoolsd.exe processes on Windows guest operating systems
    If you install VMware Tools on Windows guest operating systems (XP and later) and start the Windows Performance Monitor when the system is idle, you might notice that the two vmtoolsd.exe processes have memory leak.

    This issue is resolved in this release.

  • VMware Tools SVGA driver might cause Windows 8 virtual machines to stop responding
    After you install VMware Tools, Windows 8 virtual machines might stop responding when the guest operating system is restarted.

    This issue is resolved in this release.

  • vmtoolsd fails while retrieving virtual machine information with --cmd argument
    Sometimes vmtoolsd fails when you invoke it with the command line option --cmd. This issue is observed on vmtoolsd versions 9.0.1 and 9.0.5.

    This issue is resolved in this release.
  • When you install VMware Tools using Operating System Specific packages the /tmp/vmware-root directory fills up with vmware-db.pl.* files
    When you install VMware Tools using OSPs you can see an increase in the number of log files present in the /tmp/vmware-root directory. This issue is observed on SUSE Linux Enterprise Server 11 Service Pack 2 and RedHat Enterprise Linux 6 virtual machines.

    This issue is resolved in this release.

  • VMware Tools installation results in broken symbolic links in /usr/bin/vmware-user-wrapper
    When you install or upgrade VMware Tools, the /usr/bin/vmware-user-wrapper symbolic links might be broken. This issue is observed on Linux guest operating system.

    This issue is resolved in this release.

  • Guestinfo plugin fails to collect IPv4 routing table when VLANs are in use in guest operating system
    If you configure the SUSE Linux Enterprise Server 11 virtual machine with VLAN interfaces of the form eth0.100, eth0.200 and then install VMware Tools. The guest info plugin fails to parse the /proc/net/route and /proc/net/ipv6 and logs multiple messages to the system log.

    This issue is resolved in this release.

  • vCenter protect agent displays a warning message for unsigned executable during VMware Tools update
    When you attempt VMware Tools update on an older ESXi 5.1.x Server, the vCenter protect agent displays the Unregistering VSS driver warning message indicating the use of an unsigned executable. Including the executable to the list of files copied to the install folder resolves this issue.

    This issue is resolved in this release.

Known Issues

Installation and Upgrade Issues

  • Inventory objects might not be visible after upgrading a vCenter Server Appliance configured with Postgres database
    When a vCenter Server Appliance configured with Postgres database is upgraded from 5.0 Update 2 to 5.1 Update 1, inventory objects such as datacenters, vDS and so on that existed before the upgrade might not be visible. This issue occurs when you use vSphere Web Client to connect to vCenter Server appliance.

    Workaround: Restart the Inventory service after upgrading vCenter Server Appliance.

  • For Auto Deploy Stateful installation, cannot use firstdisk argument of ESX on systems that have ESX/ESXi already installed on USB
    You configure the host profile for a host that you want to set up for Stateful Install with Auto Deploy. As part of configuration, you select USB as the disk, and you specify esx as the first argument. The host currently has ESX/ESXi installed on USB. Instead of installing ESXi on USB, Auto Deploy installs ESXi on the local disk.

    Workaround: None.

  • Auto Deploy PowerCLI cmdlets Copy-DeployRule and Set-DeployRule require object as input
    When you run the Copy-DeployRule or Set-DeployRule cmdlet and pass in an image profile or host profile name, an error results.

    Workaround: Pass in the image profile or host profile object.

  • Applying host profile that is set up to use Auto Deploy with stateless caching fails if ESX is installed on the selected disk
    You use host profiles to set up Auto Deploy with stateless caching enabled. In the host profile, you select a disk on which a version of ESX (not ESXi) is installed. When you apply the host profile, an error that includes the following text appears.
    Expecting 2 bootbanks, found 0

    Workaround: Remove the ESX software from the disk, or select a different disk to use for stateless caching.

  • vSphere Auto Deploy no longer works after a change to the IP address of the machine that hosts the Auto Deploy server
    You install Auto Deploy on a different machine than the vCenter Server, and change the IP address of the machine that hosts the Auto Deploy server. Auto Deploy commands no longer work after the change.

    Workaround: Restart the Auto Deploy server service.
    net start vmware-autodeploy-waiter
    If restarting the service does not resolve the issue, you might have to reregister the Auto Deploy server. Run the following command, specifying all options.
    autodeploy-register.exe -R -a vCenter-IP -p vCenter-Port -u user_name -w password -s setup-file-path

  • On HP DL980 G7, ESXi hosts do not boot through Auto Deploy when onboard NICs are used
    You cannot boot an HP DL980 G7 system using Auto Deploy if the system is using the onboard (LOM Netxen) NICs for PXE booting.

    Workaround: Install an add-on NIC approved by HP on the host, for example HP NC3 60T and use that NIC for PXE booting.

  • A live update with esxcli fails with a VibDownloadError
    A user performs two updates in sequence, as follows.

    1. A live install update using the esxcli software profile update or esxcli vib update command.
    2. A reboot required update.

    The second transaction fails. One common failure is signature verification, which can be checked only after the VIB is downloaded.

    Workaround: Resolving the issue is a two-step process.

    1. Reboot the ESXi host to clean up its state.
    2. Repeat the live install.

  • ESXi scripted installation fails to find the kickstart (ks) file on a CD-ROM drive when the machine does not have any NICs connected
    When the kickstart file is on a CD-ROM drive in a system that does not have any NICs connected, the installer displays the error message: Can't find the kickstart file on cd-rom with path <path_to_ks_file>.

    Workaround: Reconnect the NICs to establish network connection, and retry the installation.

  • Scripted installation fails on the SWFCoE LUN
    When the ESXi installer invokes installation using the kickstart (ks) file, all the FCoE LUNs have not yet been scanned and populated by the time installation starts. This causes the scripted installation on any of the LUNs to fail. The failure occurs when the https, http, or ftp protocol is used to access the kickstart file.

    Workaround: In the %pre section of the kickstart file, include a sleep of two minutes:
    %pre --interpreter=busybox
    sleep 120

  • Potential problems if you upgrade vCenter Server but do not upgrade Auto Deploy server
    When you upgrade vCenter Server, vCenter Server replaces the 5.0 vSphere HA agent (vmware-fdm) with a new agent on each ESXi host. The replacement happens each time an ESXi host reboots. If vCenter Server is not available, the ESXi hosts cannot join a cluster.

    Workaround: If possible, upgrade the Auto Deploy server.
    If you cannot upgrade the Auto Deploy server, you can use Image Builder PowerCLI cmdlets included with vSphere PowerCLI to create an ESXi 5.0 image profile that includes the new vmware-fdm VIB. You can supply your hosts with that image profile.

    1. Add the ESXi 5.0 software depot and add the software depot that contains the new vmware-fdm VIB.
      Add-EsxSoftwareDepot C:\Path\VMware-Esxi-5.0.0-buildnumber-depot.zip Add-EsxSoftwareDepot http://vcenter server/vSphere-HA-depot
    2. Clone the existing image profile and add the vmware-fdm VIB.
      New-EsxImageProfile -CloneProfile "ESXi-5.0.0-buildnumber-standard" -name "Imagename" Add-EsxSoftwarePackage -ImageProfile "ImageName" -SoftwarePackage vmware-fdm
    3. Create a new rule that assigns the new image profile to your hosts and add the rule to the ruleset.
      New-DeployRule -Name "Rule Name" -Item "Image Name" -Pattern "my host pattern" Add-DeployRule -DeployRule "Rule Name"
    4. Perform a test and repair compliance operation for the hosts.
      Test-DeployRuleSetCompliance Host_list

  • If Stateless Caching is turned on, and the Auto Deploy server becomes unavailable, the host might not automatically boot using the stored image
    In some cases, a host that is set up for stateless caching with Auto Deploy does not automatically boot from the disk that has the stored image if the Auto Deploy server becomes unavailable. This can happen even if the boot device that you want is next in logical boot order. What precisely happens depends on the server vendor BIOS settings.

    Workaround: Manually select the disk that has the cached image as the boot device.

  • During upgrade of ESXi 5.0 hosts to ESXi 5.1 with ESXCLI, VMotion and Fault Tolerance (FT) logging settings are lost
    On an ESXi 5.0 host, you enable vMotion and FT for a port group. You upgrade the host by running the command esxcli software profile update. As part of a successful upgrade, the vMotion settings and the logging settings for Fault Tolerance are returned to the default settings, that is, disabled.

    Workaround: Use vSphere Upgrade Manager to upgrade the hosts, or return vMotion and Fault Tolerance to their pre-upgrade settings manually.

Networking Issues
  • On an SR-IOV enabled ESXi host, virtual machines associated with virtual functions might fail to start
    When SR-IOV is enabled on ESXi 5.1 hosts with Intel ixgbe NICs and if several virtual functions are enabled in this environment, some virtual machines might fail to start.
    Messages similar to the following are displayed in the vmware.log file:
    2013-02-28T07:06:31.863Z| vcpu-1| I120: Msg_Post: Error
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1)
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ PCIPassthruChangeIntrSettings: 0a:17.3 failed to register interrupt (error code 195887110)
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/5122262e-ab950f8e-cd4f-b8ac6f917d68/VMLibRoot/VMLib-RHEL6.2-64-HW7-default-3-2-1361954882/vmwar
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support.
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.vmx86]
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ To collect data to submit to VMware technical support, run "vm-support".
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.response] We will respond on the basis of your support entitlement.

    Workaround: Reduce the number of virtual functions associated with the affected virtual machine and start it.

  • System stops responding during TFTP/HTTP transfer when provisioning ESXi 5.1 or 5.0 U1 with Auto Deploy
    When provisioning ESXi 5.1 or 5.0 U1 with Auto Deploy on Emulex 10GbE NC553i FlexFabric 2 Ports using the latest open-source gPXE, the system stops responding during TFTP/HTTP transfer.

    Emulex 10GbE PCI-E controllers are memory-mapped controllers. The PXE/UNDI stack running on this controller must switch to big real mode from real mode during the PXE TFTP/HTTP transfer to program the device-specific registers located above 1MB in order to send and receive packets through the network. During this process, CPU interrupts are inadvertently enabled, which causes the system to stop responding when other device interrupts are generated during the CPU mode switching.

    Workaround: Upgrade the NIC firmware to build 4.1.450.7 or later.

  • Changes to the number of ports on a standard virtual switch do not take effect until host is rebooted
    When you change the number of ports on a standard virtual switch, the changes do not take effect until you reboot the host. This differs from the behavior with a distributed virtual switch, where changes to the number of ports take effect immediately.

    When changing the number of ports on a standard virtual switch, ensure that the total number of ports on the host, from both standard and distributed switches, does not exceed 4096.

    Workaround: None.

  • Administrative state of a physical NIC not reported properly as down
    Administratively setting a physical NIC state to down does not conform to IEEE standards. When a physical NIC is set to down through the virtual switch command, it causes two known problems:
    • ESXi experiences a traffic increase it cannot handle that wastes network resources at the physical switch fronting ESXi and in resources in ESXi itself.

    • The NIC behaves in an unexpected way. Operators expect to see the NIC powered down, but the NIC displays as still active.

    VMware recommends using the using ESXCLI network down -n vmnicN command with the following caveats:
    • This command turns off the driver only. It does not power off the NIC. When the ESXi physical network adapter is viewed from the management interface of the physical switch fronting the ESXi system, the standard switch uplink still appears to be active.

    • The administrative state of a NIC is not visible in the ESXCLI or UI. You must remember when debugging to check the state by examining /etc/vmware/esx.conf.

    • The SNMP agent report administrative state, however it will report incorrectly if the NIC was set to down when the operational state was down to begin with. It reports the admin state correctly if the NIC was set to down when the operational state was active.

    Workaround: Change the administrative state on the physical switch fronting the ESXi system to down instead of using the virtual switch command.

  • Linux driver support changes
    Device drivers for VMXNET2 or VMXNET (flexible) virtual NICs are not available for virtual machines running Linux kernel version 3.3 and later.

    Workaround: Use a VMXNET3 or e1000 virtual NIC for virtual machines running Linux kernel version 3.3 and later.

  • vSphere 5.0 network I/O control bandwidth allocation is not distributed fairly across multiple uplinks
    In vSphere 5.0, if a networking bandwidth limit is set on a resource pool while using network I/O control, this limit is enforced across a team of uplinks at the host level. This bandwidth cap is implemented by a token distribution algorithm that is not designed to fairly distribute bandwidth between multiple uplinks.

    Workaround: vSphere 5.1 network I/O control limits have been narrowed to a per uplink basis.

  • Mirrored Packet Length setting could cause a remote mirroring source session not to function
    When you configure a remote mirroring source session with the Mirrored Packet Length option set, the destination does not receive some mirrored packets. However, if you disable the option, packets are again received.
    If the Mirrored Packet Length option is set, packets longer than the specified length are truncated and packets are dropped. Lower layer code will not do fragmentation and recalculate checksum for the dropped packets. Two things might cause packets to drop:

    • The Mirrored Packet Length is greater than the maximum transmission unit (MTU)
      If TSO is enabled in your environment, the original packets could be very large. After being truncated by the Mirrored Packet Length, they are still larger than the MTU, so they are dropped by the physical NIC.

    • Intermediate switches perform L3 check
      Some truncated packets can have the wrong packet length and checksum. Some advanced physical switches check L3 information and drop invalid packets. The destination does not receive the packets.

Workaround:

    • If TCP Segmentation Offload (TSO) is enabled, disable the Mirrored Packet Length option.

    • You can enable or disable L3 check on some switches, such as Cisco's 4500 series switch. If these switches are in use, disable the L3 check. For switches that cannot be configured, disable the Mirrored Packet Length option.
  • Enabling more than 16 VMkernel network adapters causes vMotion to fail
    vSphere 5.x has a limit of 16 VMkernel network adapters enabled for vMotion per host. If you enable more than 16 VMkernel network adapters for vMotion on a given host, vMotion migrations to or from that host might fail. An error message in the VMkernel logs on ESXi says Refusing request to initialize 17 stream ip entries, where the number indicates how many VMkernel network adapters you have enabled for vMotion.

    Workaround: Disable vMotion VMkernel network adapters until only a total of 16 are enabled for vMotion.

  • vSphere network core dump does not work when using a nx_nic driver in a VLAN environment
    When network core dump is configured on a host that is part of a VLAN, network core dump fails when the NIC uses a QLogic Intelligent Ethernet Adapters driver (nx_nic). Received network core dump packets are not tagged with the correct VLAN tag if the uplink adapter uses nx_nic.

    Workaround: Use another uplink adapter with a different driver when configuring network coredump in a VLAN.

  • If the kickstart file for a scripted installation calls a NIC already in use, the installation fails
    If you use a kickstart file to set up a management network post installation, and you call a NIC that is already in use from the kickstart file, you see the following error message: Sysinfo error on operation returned status: Busy. Please see the VMkernel log for detailed error information.

    The error is encountered when you initiate a scripted installation on one system with two NICs: a NIC configured for SWFCoE/SWiSCSI, and a NIC configured for networking. If you use the network NIC to initiate the scripted installation by providing either netdevice=<nic> or BOOTIF=<MAC of the NIC> at boot-options, the kickstart file uses the other NIC, netdevice=<nic configured for SWFCoE / SWiSCSI>, in the network line to configure the management network.

    Installation (partitioning the disks) is successful, but when the installer tries to configure the management-network for the host with the network parameters provided in the kickstart file, it fails because the NIC was in use by SWFCoE/SWiSCSI.

    Workaround: Use an available NIC in the kickstart file for setting up a management network after installation.

  • Virtual machines running ESX that also use VMXNET3 as the pNIC might crash
    Virtual machines running ESX as a guest that also use VMXNET3 as the pNIC might crash because support for VMXNET3 is experimental. The default NIC for an ESX virtual machine is e1000, so this issue is encountered only when you override the default and choose VMXNET3 instead.

    Workaround: Use e1000 or e1000e as the pNIC for the ESX virtual machine.

  • Error message is displayed when a large number of dvPorts is in use
    When you power on a virtual machine with dvPort on a host that already has a large number of dvPorts in use, an Out of memory or Out of resources error is displayed. This can also occur when you list the switches on a host using an esxcli command.

    Workaround: Increase the dvsLargeHeap size.

    1. Change the host's advanced configuration option:
      • esxcli command: esxcfg-advcfg -s /Net/DVSLargeHeapMaxSize 100
      • Virtual Center: Browse to Host configuration -> Software Panel -> Advanced Settings -> Under "Net", change the DVSLargeHeapMaxSize value from 80 to 100.
      • vSphere 5.1 Web Client: Browse to Manage host -> Settings -> Advanced System Settings -> Filter. Change the DVSLargeHeapMaxSize value from 80 to 100.
    2. Capture a host profile from the host. Associate the profile with the host and update the answer file.
    3. Reboot the host to confirm the value is applied.

    Note: The max value for /Net/DVSLargeHeapMaxSize is 128.

    Please contact VMware Support if you face issues during a large deployment after changing /Net/DVSLargeHeapMaxSize to 128 and logs display either of the following error messages:

    Unable to Add Port; Status(bad0006)= Limit exceeded

    Failed to get DVS state from vmkernel Status (bad0014)= Out of memory

  • ESXi fails with Emulex BladeEngine-3 10G NICs (be2net driver)
    ESXi might fail on systems that have Emulex BladeEngine-3 10G NICs when a vCDNI-backed network pool is configured using VMware vCloud Director. You must obtain an updated device driver from Emulex when configuring a network pool with this device.

    Workaround: None.

Storage Issues

  • RDM LUNs get detached from virtual machines that migrate from VMFS datastore to NFS datastore
    If you use the vSphere Web Client to migrate virtual machines with RDM LUNs from VMFS datastore to NFS datastore, the migration operation completes without any error or warning messages, but the RDM LUNs get detached from the virtual machine after migration. However, the migration operation creates a vmdk file with size same as that of RDM LUN on NFS datastore, to replace the RDM LUN.
    If you use vSphere Client, an appropriate error message is displayed in the compatibility section of the migration wizard.

    Workaround: None
  • VMFS5 datastore creation might fail when you use an EMC Symmetrix VMAX/VMAXe storage array
    If your ESXi host is connected to a VMAX/VMAXe array, you might not be able to create a VMFS5 datastore on a LUN presented from the array. If this is the case, the following error will appear: An error occurred during host configuration. The error is a result of the ATS (VAAI) portion of the Symmetrix Enginuity Microcode (VMAX 5875.x) preventing a new datastore on a previously unwritten LUN.

    Workaround:

    1. Disable Hardware Accelerated Locking on the ESXi host.
    2. Create a VMFS5 datastore.
    3. Reenable Hardware Accelerated Locking on the host.

    Use the following tasks to disable and reenable the Hardware Accelerated Locking parameter.

    In the vSphere Web Client

    1. Browse to the host in the vSphere Web Client navigator.
    2. Click the Manage tab, and click Settings.
    3. Under System, click Advanced System Settings.
    4. Select VMFS3.HardwareAcceleratedLocking and click the Edit icon.
    5. Change the value of the VMFS3.HardwareAcceleratedLocking parameter:
      • 0 disabled
      • 1 enabled

    In the vSphere Client

    1. In the vSphere Client inventory panel, select the host.
    2. Click the Configuration tab, and click Advanced Settings under Software.
    3. Change the value of the VMFS3.HardwareAcceleratedLocking parameter:
      • 0 disabled
      • 1 enabled

  • Attempts to create a GPT partition on a blank disk might fail when using Storagesystem::updateDiskPartitions()
    You can use the Storagesystem::computeDiskPartitionInfo API to retrieve disk specification, and then use the disk specification to label the disk and create a partition with Storagesystem::updateDiskPartitions(). However, if the disk is initially blank and the target disk format is GPT, your attempts to create the partition might fail.

    Workaround: Use DatastoreSystem::createVmfsDatastore instead to label and partition a blank disk, and to create a VMFS5 datastore.

  • Attempts to create a diagnostic partition on a GPT disk might fail
    If a GPT disk has no partitions, or the tailing portion of the disk is empty, you might not be able to create a diagnostic partition on the disk.

    Workaround: Avoid using GPT-formatted disks for diagnostic partitions. If you must use an existing blank GPT disk for the diagnostic partition, convert the disk to the MBR format.

    1. Create a VMFS3 datastore on the disk.
    2. Remove the datastore.

    The disk format changes from GPT to MBR.

  • ESXi cannot boot from a FCoE LUN that is larger than 2TB and accessed through an Intel FCoE NIC
    When you install ESXi on a FCoE boot LUN that is larger than 2TB and is accessed through an Intel FCoE NIC, the installation might succeed. However, when you attempt to boot your ESXi host, the boot fails. You see the error messages: ERROR: No suitable geometry for this disk capacity! and ERROR: Failed to connect to any configured disk! at BIOS time.

    Workaround: Do not install ESXi on a FCoE LUN larger than 2TB if it is connected to the Intel FCoE NIC configured for FCoE boot. Install ESXi on a FCoE LUN that is smaller than 2TB.

Server Configuration Issues

  • Applying host profiles might fail when accessing VMFS folders through console
    If a user is accessing the VMFS datastore folder through the console at the same time a host profile is being applied to the host, the remediation or apply task might fail. This failure occurs when stateless caching is enabled on the host profile or if an auto deploy installation occurred.

    Workaround: Do not access the VMFS datastore through the console while remediating the host profile.

  • Leading white space in login banner causes host profile compliance failure
    When you edit a host profile and change the text for the Login Banner (Message of the Day) option, but add a leading white space in the banner text, a compliance error occurs when the profile is applied. The compliance error Login banner has been modified appears.

    Workaround: Edit the host profile and remove the leading white space from the Login Banner policy option.

  • Host profile extracted from ESXi 5.0 host fails to apply to ESX 5.1 host with Active Directory enabled
    When applying a host profile with Active Directory enabled that was originally extracted from an ESXi 5.0 host to an ESX 5.1 host, the apply task fails. Setting the maximum memory size for the likewise system resource pool might cause an error to occur. When Active Directory is enabled, the services in the likewise system resource pool consume more than the default maximum memory limit for ESXi 5.0 captured in an ESXi 5.0 host profile. As a result, applying an ESXi 5.0 host profile fails during attempts to set the maximum memory limit to the ESXi 5.0 levels.

    Workaround: Perform one of the following:

    • Manually edit the host profile to increase the maximum memory limit for the likewise group.
      1. From the host profile editor, navigate to the Resource Pool folder, and view host/vim/vmvisor/plugins/likewise.
      2. Modify the Maximum Memory (MB) setting from 20 (the ESXi 5.0 default) to 25 (the ESXi 5.1 default).
    • Disable the subprofile for the likewise group. Do one of the following:
      • In the vSphere Web Client, edit the host profile and deselect the checkbox for the Resource Pool folder. This action disables all resource pool management. You can disable this specifically for the host/vim/vmvisor/plugins/likewise item under the Resource Pool folder.
      • In the vSphere Client, right-click the host profile and select Enable/Disable Profile Configuration... from the menu.

  • Host gateway deleted and compliance failures occur when ESXi 5.0.x host profile re-applied to stateful ESXi 5.1 host
    When an ESXi 5.0.x host profile is applied to a freshly installed ESXi 5.1 host, the profile compliance status is noncompliant. After applying the same profile again, it deletes the host's gateway IP and the compliance status continues to show as noncompliant with the IP route configuration doesn't match the specification status message.

    Workaround: Perform one of the following workarounds:

    • Login to the host through DCUI and add the default gateway manually with the following esxcli command:
      esxcli network ip route ipv4 add --gateway xx.xx.xx.xx --network yy.yy.yy.yy
    • Extract a new host profile from the ESX 5.1 host after applying the ESX 5.0 host profile once. Migrate the ESX 5.1 host to the new ESX 5.1-based host profile.

  • Compliance errors might occur after stateless caching enabled on USB disk
    When stateless caching to USB disks is enabled on a host profile, compliance errors might occur after remediation. After rebooting the host so that the remediated changes are applied, the stateless caching is successful, but compliance failures continue.

    Workaround: No workaround is available.

  • Hosts with large number of datastores time out while applying host profile with stateless caching enabled
    A host that has a large number of datastores times out when applying a host profile with stateless caching enabled.

    Workaround: Use the vSphere Client to increase the timeout:

    1. Select Administrator > vCenter Server Settings.
    2. Select Timeout Settings.
    3. Change the values for Normal Operations and Long Operations to 3600 seconds.

  • Cannot extract host profile from host when IPv4 is disabled on vmknics
    If you remove all IPv4 addresses from all vmknics, you cannot extract a host profile from that host. This action affects hosts provisioned with auto-deploy the most, as host profiles is the only way to save the host configuration in this environment.

    Workaround: Assign as least one vmknic to one IPv4 address.

  • Applying host profile fails when applying a host profile extracted from an ESXi 4.1 host on an ESXi 5.1 host
    If you set up a host with ESXi 4.1, extract a host profile from this host (with vCenter Server), and attempt to attach a profile to an ESXi 5.1 host, the operation fails when you attempt to apply the profile. You might receive the following error: NTP service turned off.

    The NTPD service could be running (on state) even without providing an NTP server in /etc/ntp.conf for ESXi 4.1. ESXi 5.1 needs an explicit NTP server for the service to run.

    Workaround: Turn on the NTP service by adding a valid NTP server in /etc/ntp.conf and restart the NTP daemon on the 5.1 host. Confirm that the service persists after the reboot. This action ensures the NTP service is synched for the host and the profile being applied to it.

  • Host profile shows noncompliant after profile successfully applied
    This problem occurs when extracting a host profile from an ESXi 5.0 host and applying it to an ESXi 5.1 host that contains a local SAS device. Even when the host profile remediation is successful, the host profile compliance shows as noncompliant.

    You might receive errors similar to the following:

    • Specification state absent from host: device naa.500000e014ab4f70 Path Selection Policy needs to be set to VMW_PSP_FIXED
    • Specification state absent from host: device naa.500000e014ab4f70 parameters needs to be set to State = on" Queue Full Sample Size = "0" Queue Full Threshold = "0"

    The ESXi 5.1 host profile storage plugin filters out local SAS device for PSA and NMP device configuration, while ESXi 5.0 contains such device configurations. This results in a missing device when applying the older host profile to a newer host.

    Workaround: Manually edit the host profile, and remove the PSA and NMP device configuration entries for all local SAS devices. You can determine if a device is a local SAS by entering the following esxcli command:
    esxcli storage core device list

    If the following line is returned, the device is a local SAS:
    Is Local SAS Device

  • Default system services always start on ESXi hosts provisioned with Auto Deploy
    For ESXi hosts provisioned with Auto Deploy, the Service Startup Policy in the Service Configuration section of the associated host profile is not fully honored. In particular, if one of the services that is turned on by default on ESXi has a Startup Policy value of off, that service still starts at the boot time on the ESXi host provisioned with Auto Deploy.

    Workaround: Manually stop the service after booting the ESXi host.

  • Information retrieval from VMWARE-VMINFO-MIB does not happen correctly after an snmpd restart
    Some information from VMWARE-VMINFO-MIB might be missing during SNMPWalk after you restart the snmpd daemon using /etc/init.d/snmpd restart from the ESXi Shell.

    Workaround: Do not use /etc/init.d/snmpd restart. You must use the esxcli system snmp set --enable command to start or stop the SNMP daemon. If you used /etc/init.d/snmpd restart to restart snmpd from the ESXi Shell, restart Hostd, either from DCUI or by using /etc/init.d/hostd restart from the ESXi Shell.

vCenter Server and vSphere Client Issues
  • Enabling or Disabling View Storage Accelerator might cause ESXi hosts to lose connectivity to vCenter Server
    If VMware View is deployed with vSphere 5.1, and a View administrator enables or disables View Storage Accelerator in a desktop pool, ESXi 5.1 hosts might lose connectivity to vCenter Server 5.1.

    The View Storage Accelerator feature is also called Content Based Read Caching. In the View 5.1 View Administrator console, the feature is called Host caching.

    Workaround: Do not enable or disable View Storage Accelerator in View environments deployed with vSphere 5.1.

Virtual Machine Management Issues
  • Virtual Machine compatibility upgrade from ESX 3.x and later (VM version 4) incorrectly configures the Windows virtual machine Flexible adapter to the Windows system default driver
    If you have a Windows guest operating system with a Flexible network adapter that is configured for the VMware Accelerated AMD PCnet Adapter driver, when you upgrade the virtual machine compatibility from ESX 3.x and later (VM version 4) to any later compatibility setting, for example, ESXi 4.x and later (VM version 7),Windows configures the flexible adapter to the Windows AMD PCNET Family PCI Ethernet Adapter default driver.
    This misconfiguration occurs because the VMware Tools drivers are unsigned and Windows picks up the signed default Windows driver. Flexible adapter network settings that existed before the compatibility upgrade are lost, and the network speed of the NIC changes from 1Gbps to 10Mbps.

    Workaround: Configure the Flexible network adapters to use the VMXNET driver from the Windows guest OS after you upgrade the virtual machine's compatibility. If your guest is updated with ESXi5.1 VMware Tools, the VMXNET driver is installed in the following location: C:\Program Files\Common Files\VMware\Drivers\vmxnet\.

  • When you install VMware Tools on a virtual machine and reboot, the network becomes unusable
    On virtual machines with CentOS 6.3 and Oracle Linux 6.3 operating systems, the network becomes unusable after a successful installation of VMware Tools and a reboot of the virtual machine. When you attempt to manually get the IP address from a DHCP server or set a static IP address from the command line, the error Cannot allocate memory appears.
    The problem is that the Flexible network adapter, which is used by default, is not a good choice for those operating systems.

    Workaround: Change the network adapter from Flexible to E1000 or VMXNET 3, as follows:

    1. Run the vmware-uninstall-tools.pl command to uninstall VMware Tools.
    2. Power off the virtual machine.
    3. In the vSphere Web Client, right-click the virtual machine and select Edit Settings.
    4. Click Virtual Hardware, and remove the current network adapter by clicking the Remove icon.
    5. Add a new Network adapter, and choose the adapter type E1000 or VMXNET 3.
    6. Power on the virtual machine.
    7. Reinstall VMware Tools.

  • Clone or migration operations that involve non-VMFS virtual disks on ESXi fail with an error
    No matter whether you use the vmkfstools command or the client to perform a clone, copy, or migration operation on the virtual disks of hosted formats, the operation fails with the following error message: The system cannot find the file specified.

    Workaround: To perform a clone, copy, or migration operation on the virtual disks of hosted formats, you need to load the VMkernel multiextent module into ESXi.

    1. Log in to ESXi Shell and load the multiextent module.
      # vmkload_mod multiextent
    2. Check if any of your virtual machine disks are of a hosted type. Hosted disks end with the -s00x.vmdk extension.
    3. Convert virtual disks in hosted format to one of the VMFS formats.
      1. Clone source hosted disk test1.vmdk to test2.vmdk.
        # vmkfstools -i test1.vmdk test2.vmdk -d zeroedthick|eagerzereodthick|thin
      2. Delete the hosted disk test1.vmdk after successful cloning.
        # vmkfstools -U test1.vmdk
      3. Rename the cloned vmfs type disk test2.vmdk to test1.vmdk.
        # vmkfstools -E test2.vmdk test1.vmdk
    4. Unload the multiextent module.
      # vmkload_mod -u multiextent

  • A virtual machine does not have an IP address assigned to it and does not appear operational
    This issue is caused by a LUN reset request initiated from a guest OS. This issue is specific to IBM XIV Fibre Channel array with software FCoE configured in ESXi hosts. Virtual machines that reside on the LUN show the following problems:

    • No IP address is assigned to the virtual machines.
    • Virtual machines cannot power on or power off.
    • No mouse cursor is showing inside the console. As a result, there is no way to control or interact with the affected virtual machine inside the guest OS.

    Workaround: From your ESXi host, reset the LUN where virtual machines that experience troubles reside.

    1. Run the following command to get the LUN's information:
      # vmkfstools -P /vmfs/volumes/DATASTORE_NAME
    2. Search for the following line in the output to obtain the LUN's UID:
      Partitions spanned (on 'lvm'): eui.001738004XXXXXX:1
      eui.001738004XXXXXX is the device UID.
    3. Run the following command to reset the LUN:
      # vmkfstools -L lunreset /vmfs/devices/disks/eui.001738004XXXXXX
    4. If a non-responsive virtual machine resides on a datastore that has multiple LUNs associated with it, for example, added extents, perform the LUN reset for all datastore extents.

Migration Issues
  • Attempts to use Storage vMotion to migrate multiple linked-clone virtual machines fail
    This failure typically affects linked-clone virtual machines. The failure occurs when the size of delta disks is 1MB and the Content Based Read Cache (CBRC) feature has been enabled in ESXi hosts. You see the following error message: The source detected that the destination failed to resume.

    Workaround: Use one of the following methods to avoid Storage vMotion failures:

    • Use 4KB as the delta disk size.

    • Instead of using Storage vMotion, migrate powered-off virtual machines to a new datastore.

VMware HA and Fault Tolerance Issues
  • Fault tolerant virtual machines crash when set to record statistics information on a vCenter Server beta build
    The vmx*3 feature allows users to run the stats vmx to collect performance statistics for debugging support issues. The stats vmx is not compatible when Fault Tolerance is enabled on a vCenter Server beta build.

    Workaround: When enabling Fault Tolerance, ensure that the virtual machine is not set to record statistics on a beta build of vCenter Server.

Supported Hardware Issues
  • PCI Unknown Unknown status is displayed in vCenter Server on the Apple Mac Pro server
    The hardware status tab in vSphere 5.1 displays Unknown Unknown for some PCI devices on the Apple Mac Pro. This is because of missing hardware descriptions for these PCI devices on the Apple Mac Pro. The display error in the hardware status tab does not prevent these PCI devices from functioning.

    Workaround: None.

  • PCI Unknown Unknown status is displayed in vCenter Server on the AMD PileDriver
    The hardware status tab in vSphere 5.1 displays Unknown Unknown for some PCI devices on the AMD PileDriver. This is because of missing hardware descriptions for these PCI devices on the AMD PileDriver. The display error in the hardware status tab does not prevent these PCI devices from functioning.

    Workaround: None.

  • DPM is not supported on the Apple Mac Pro server
    The vSphere 5.1 distributed power management (DPM) feature is not supported on the Apple Mac Pro. Do not add the Apple Mac Pro to a cluster that has DPM enabled. If the host enters "Standby" state, it fails to exit the standby state when the power on command is issued and displays an operation timed out error. The Apple Mac Pro cannot wake from the software power off command that is used by vSphere when putting a host in standby state.

    Workaround: If the Apple Mac Pro host enters "Standby" you must power on the host by physically pressing the power button.

  • IPMI is not supported on the Apple Mac Pro server
    The hardware status tab in vSphere 5.1 does not display correct data or there is missing data for some of the hardware components on the Apple Mac Pro. This is because IPMI is not supported on the Apple Mac Pro.

    Workaround: None.

Miscellaneous Issues
  • After a network or storage interruption, syslog over TCP, syslog over SSL, and storage logging do not restart automatically
    After a network or storage interruption, the syslog service does not restart automatically in certain configurations. These configurations include syslog over TCP, syslog over SSL, and the interrupt storage logging.

    Workaround: Restart syslog explicitly by running the following command:
    esxcli system syslog reload You can also configure syslog over UDP, which restarts automatically.