VMware ESX 4.0 Update 3 Release Notes

ESX 4.0 Update 3 | 05 May 2011 | Build 398348

Last Document Update: 19 May 2011

These release notes include the following topics:

What's New
Earlier Releases of ESX 4.0
Before You Begin
Documentation
Installation and Upgrade
Patches Contained in this Release
Resolved Issues
Known Issues

What's New

The following list highlights some of the enhancements available in this release of VMware ESX:

Enhanced APD handling with automatic failover whenever the LUN rescan happens.
Inclusion of additional driver: Includes the 3ware SCSI 2.26.08.036vm40 driver. For earlier releases, this driver is available only as a separate download.
Updates VMware Tools WDDM, XPDM, and PVSCSI drivers.

Resolved Issues: In addition, this release delivers a number of bug fixes that have been documented in the Resolved Issues section.

Top of Page

Earlier Releases of ESX 4.0

Features and known issues from earlier releases of ESX 4.0 are described in the release notes for each release. To view release notes for earlier releases of ESX 4.0, click one of the following links:

Top of Page

Before You Begin

ESX, vCenter Server, and vSphere Client Version Compatibility

The VMware vSphere Compatibility Matrixes provide details of the compatibility of current and earlier versions of VMware vSphere components, including ESX, vCenter Server, the vSphere Client, and other VMware products.

Hardware Compatibility

Learn about hardware compatibility

The Hardware Compatibility Lists are available in the Web-based Compatibility Guide at http://www.vmware.com/resources/compatibility. The Web-based Compatibility Guide is a single point of access for all VMware compatibility guides and provides the option to search the guides, and save the search results in PDF format. For example, with this guide, you can verify that your server, I/O, storage, and guest operating systems, are compatible.

Subscribe to be notified of Compatibility Guide updates via
Learn about vSphere compatibility:

VMware vSphere Compatibility Matrixes (PDF)

Documentation

The VMware vSphere 4.0 Update 1 documentation has been updated and is applicable for all update releases of vSphere 4.0, including VMware vSphere 4.0 Update 3. See the ESX 4.0 Update 1 and later with vCenter Server 4.0 Update 1 and later documentation page.

Installation and Upgrade

Read the ESX and vCenter Server Installation Guide for step-by-step guidance about installing and configuring ESX and vCenter Server.

After successful installation, several configuration steps (in particular, some licensing, networking, and security configuration) are essential. Refer to the following guides in the vSphere documentation for more information on these configuration tasks.

The ESX and vCenter Server Installation Guide for information on licensing
The ESX Configuration Guide for information on networking and security

Future releases of VMware vSphere might not support VMFS version 2 (VMFS2). You should consider upgrading or migrating to VMFS version 3 or higher. See the vSphere Upgrade Guide.

Future releases of VMware vCenter Server might not support installation on 32-bit Windows operating systems. VMware recommends installing vCenter Server on a 64-bit Windows operating system. If you have VirtualCenter 2.x installed, see the vSphere Upgrade Guide for instructions about installing vCenter Server on a 64-bit operating system and preserving your VirtualCenter database.

Management Information Base (MIB) files related to ESX are not bundled with vCenter Server. Only MIB files specifically related to vCenter Server are shipped with vCenter Server 4.0.X. All MIB files can be downloaded from the VMware Web site at http://www.vmware.com/download.

Upgrading VMware Tools

VMware ESX 4.0 Update 3 requires a VMware Tools upgrade. VMware Tools is a suite of utilities that enhances the performance of the virtual machine’s guest operating system. See the VMware Tools Resolved Issues for a list of VMware Tools issues resolved in this release of ESX.

The VMware Tools RPM installer, which is available in the VMware Tools ISO image for Linux guest operating systems, has been deprecated and will be removed in a future ESX release. Use the tar.gz installer to install VMware Tools on virtual machines with Linux guest operating systems.

To determine an installed VMware Tools version, see Verifying a VMware Tools build version (KB 1003947).

Upgrading or Migrating to ESX 4.0 Update 3

ESX 4.0 Update 3 offers the following options for upgrading:

VMware vCenter Update Manager — You can upgrade from ESX 3.5 Update 5a and ESX 4.0.x by using vCenter Update Manager 4.0 Update 3. See the VMware vCenter Update Manager Administration Guide for more information.
vSphere Host Update Utility — You can upgrade from ESX 3.5 Update 5a by using the vSphere Host Update Utility 4.0 Update 3. For more information see the vSphere Upgrade Guide.
esxupgrade.sh script – You can upgrade from an ESX 3.5 Update 5a host that does not have network access. See Performing an offline upgrade from ESX 3.x to ESX 4.x (KB 1009440). If the host has network access, you can use the vSphere Host Update Utility or VMware vCenter Update Manager to perform the upgrade.
vihostupdate command of VMware vSphere Command-Line Interface (vSphere CLI) —You can upgrade from ESX 4.0.x by using the vihostupdate command. For more details, refer to vSphere Upgrade Guide and Patch Management Guide.
esxupdate command-line utility —You can upgrade from ESX 4.0.x by using esxupdate. For details, see the vSphere Upgrade Guide and Patch Management Guide.

Several upgrade tools that were supported in ESX 3.x releases are no longer supported in the current release. These tools include graphical upgrade from CD, text-mode upgrade from CD, tarball upgrade using the service console, scripted upgrade from CD or PXE server using esxupdate, and scripted upgrade from CD or PXE server using kickstart commands.

Supported Upgrade Paths for Host Upgrade to ESX 4.0 Update 3:

Upgrade Deliverables	Supported Upgrade Tools	Supported Upgrade Paths to ESX 4.0 Update 3
Upgrade Deliverables	Supported Upgrade Tools	ESX 3.5 Update 5a	ESX 4.0, including ESX 4.0 Update 1 and ESX 4.0 Update 2
`ESX-4.0.0-update03-398348.iso`	VMware vCenter Update Manager with ESX host upgrade baseline vSphere Host Update Utility	Yes	No
`update-from-esx4.0-4.0_update03.zip`	esxupdate vihostupdate	No	Yes
Patch definitions downloaded from the VMware portal (online)	VMware vCenter Update Manager with Host patch baseline	No	Yes

Notes:

Direct upgrade from ESX 3.0.x or releases prior to ESX 3.5 Update 5a is not supported. You should upgrade first to a later version that is supported, and then upgrade to ESX 4.0 Update 3.
Direct upgrade from ESX 2.5.x is not supported. You can migrate ESX 2.5.5 virtual machines to ESX 4.0 Update 3 by using Upgrade vMotion.See the vSphere Upgrade Guide.

Top of Page

Updated RPMs and Security Fixes

For a list of RPMs updated in ESX 4.0 Update 3, see Updated RPMs and Security Fixes. This document does not apply to the ESXi products.

Patches Contained in this Release

This release contains all bulletins for the ESX Server software that were released prior to the release date of this product. See the VMware Download Patches page.

See the documentation listed on the download page for more information on the contents of each patch.

Top of Page

Resolved Issues

This section describes resolved issues in this release in the following subject areas:

Backup
CIM and API
Guest Operating System
Miscellaneous
Networking
Storage
Upgrade and Installation
Virtual Machine Management
vMotion and Storage vMotion
VMware Tools

Resolved issues previously documented as known issues are marked with the † symbol.

Backup

Reverting to an existing snapshot can cause incremental backups based on CBT to become inconsistent (KB 1021607)

CIM and API

vCenter Server reports the service tag of the blade chassis incorrectly
For blade servers that are running ESX, vCenter Server incorrectly reports the service tag of the blade chassis instead of that for the blade. On a Dell or IBM blade server that is managed by vCenter Server, the service tag number is listed in the System section of the vCenter Server under vCenter Server > Configuration tab under Processors. This issue occurs due to the incorrect value for the SerialNumber property of the Fixed CIM OMC_Chassis instance.

This issue is resolved in this release.

Guest Operating System

Timer interrupts are delivered to the VMI-enabled guest operating system at an excessive rate †
An issue in the Virtual Machine Interface (VMI) timer causes timer interrupts to be delivered to the guest operating system at an excessive rate. This issue might occur after a vMotion migration of a virtual machine that was up for a relatively long time, such as for one hundred days.

This issue is resolved in this release.
The virtual machine might fail on Windows 7 or Windows Server 2008 R2 guest operating systems in very specific situations when using Windows Media Player †
VMware supports Windows Media Player on both Windows 7 (32 and 64 bit) and Windows Server 2008 R2 guest operating systems. However, in rare circumstances, maximizing the Windows Media Player window while playing a video might cause the virtual machine to crash.

This issue is resolved in this release.
For Windows 7 guests, video output might be displayed incorrectly †
Windows Media Player in a Windows 7 guest may incorrectly display video files when the video is scaled.

This issue is resolved in this release.
Mouse movements in RDP sessions to Windows virtual machines are affected by MKS console mouse movements

If an administrator uses the vSphere Client to open a console to a Windows virtual machine on which multiple users are logged in through terminal sessions, mouse movements of the users might become synchronized with the mouse movements of the administrator.

This issue is resolved in this release.

vmrun command fails to run on Ubuntu 10.04 guest operating systems
The listProcessesInGuest vmrun command might fail to run on Ubuntu 10.04 guest operating systems. The guest operating system displays an error message similar to the following:

Error: Invalid user name or password for the guest OS

This issue is resolved in this release.
The default settings for memory size in the RHEL and Ubuntu 32-bit and 64-bit virtual machines is updated
The minimum and default memory sizes for RHEL and Ubuntu 32-bit and 64-bit guest operating systems are updated as follows:

For RHEL 6 32-bit, minimum memory is updated from 1GB to 512MB, default recommended memory is updated from 2GB to1GB, maximum recommended memory is updated from 64GB to 16GB, and hard disk size is updated from 8GB to 16 GB.
For RHEL 6 64-bit, default recommended memory is updated from 2GB to1GB, and hard disk size is updated from 8GB to 16GB.
For Ubuntu 32-bit and 64-bit, minimum recommended memory is updated from 64MB to 256MB.
Windows guest operating system might fail with vmx_fb.dll error
Windows guest operating systems on which you have installed the VMware driver for Windows XP Display Driver Model (XPDM) might fail with a vmx_fb.dll error and display a blue screen.

The issue is resolved in this release.

Miscellaneous

ESX host intermittently loses connection with vCenter Server due to socket exhaustion
This issue is resolved in the ESX 4.0 Update 3 release. ESX400-201104401-SG already contains the fix for this issue. This patch was released before ESX 4.0 Update 3. For more information see KB 1037258.

Performance chart data for networking displays incorrect information
The stacked per-virtual machine performance chart data for networking displays incorrect information. You can access the chart from Chart Options in the Advanced Settings of the Performance tab. The network transmit and receive statistics of a virtual machine connected to the Distributed Virtual Switch (DVS) are interchanged and incorrectly displayed.

This issue is resolved in this release.
lokkit command might cause ESX hosts to fail
Do not run the lokkit command. If you do run it, you must click Cancel to ensure that it does not harm the service console. If you run the lokkit command from the service console of an ESX host, a Firewall Configuration window containing security level or network options with three buttons is displayed: OK, Customize, and Cancel. If you click OK without changing the security level or network options, a setenforce: SELinux is disabled message might appear on the service console. The ESX host fails and does not reboot. This issue occurs due to the presence of the lokkit command in an obsolete system-config-securitylevel-tui package. This package was installed on all ESX hosts prior to ESX 4.0 Update 3.

This issue is resolved in this release.
When a user account that is accessing the service console is a member of more than 32 groups, an ESX host restarts, becomes unresponsive, or fails with a purple diagnostic screen
These issues are resolved in this release. In such situations a warning message similar to the following is written to the VMkernel log:

Sep 9 02:16:47 osdc-cpdqa0077 kernel: [74509.293081] cannot set all groups in vmkernel
ESX host sometimes fails due to vmkiscsid.log file size
When you run VMware ESX 4.x with a software iSCSI initiator, the /var/log/vmkiscsid.log file might not get cleared, unlike other syslog-generated log files. As a result, this file grows to a very large size if the ESX host cannot communicate with the iSCSI storage.

This issue is resolved in this release. After installing this update if the vmkiscsid.log exceeds 100KB in size, the logrotate utility creates a new file, up to six files. After the sixth file, the first file is overwritten with new messages.
vSphere Client displays incorrect provisioned space for a powered-off virtual machine
The ESX host does not consider the memory reservation while calculating the provisioned space of a powered-off virtual machine. As a result, the vSphere Client might display a discrepancy in the provisioned space values while the virtual machine is powered on or powered off.

This issue is resolved in this release.
ESX host might fail when USB devices are connected to EHCI controllers
When you connect USB devices (including baseboard management controllers (BMC) such as iLo or DRAC-based USB devices) to EHCI controllers, an issue with memory corruption might sometimes cause an ESX host to fail with a purple screen and display error messages similar to the following:

2010-12-11T10:11:30.683Z cpu1:2606)@BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4803 - Usage error in dlmalloc
2010-12-11T10:11:30.684Z cpu1:2606)Code start: 0x418031000000 VMK uptime: 0:03:35:09.476
2010-12-11T10:11:30.685Z cpu1:2606)0x412208b87b10:[0x418031069302]Panic@vmkernel#nover+0xa9 stack: 0x410014b12e80
2010-12-11T10:11:30.687Z cpu1:2606)0x412208b87b30:[0x4180310285eb]DLM_free@vmkernel#nover+0x602 stack: 0x1
2010-12-11T10:11:30.688Z cpu1:2606)0x412208b87b70:[0x418031038ef1]Heap_Free@vmkernel#nover+0x164 stack: 0x3e8

This issue is resolved in this release.
ESX host fails and displays a purple screen due to a TTY-related race condition
An ESX host might fail with a purple screen that displays an error message similar to the following when multiple threads trying to use the same TTY cause a race condition:

ASSERT bora/vmkernel/user/userTeletype.c:969 cr2=0xff9fcfec cr3=0xa114f000 cr4=0x128

This issue is resolved in this release.
The VMkernel log reports the log spew: usbdev_ioctl: REAPURBDELAY (KB 1029451)
Performing a downgrade or upgrade by using the Dell Update Package (DUP) utility might fail on ESX 4.0 hosts

This issue is resolved in this release.

Networking

Traffic shaping values are reset after ESX host restart
If you configure the traffic shaping value on a vDS or vSwitch to greater than 4GB, the value is reset to below 4GB after you restart the ESX host. This issue causes the traffic shaper to shape traffic using much lower values, resulting in very low network bandwidth. For example, if you set the traffic shaping to a maximum bandwidth of 6Gbps, the value changes to about 1.9Gbps after you restart the ESX host.

This issue is resolved in this release.
bnx2 NIC reset causes ESX host to fail
A bnx2 NIC reset might fail due to firmware synchronization timeout, and in turn cause the ESX host to fail with a purple screen. The following is an example of a backtrace of this issue:

0x4100c178f7f8:[0x41802686d9f4]bnx2_poll+0x167 stack: 0x4100c178f838
0x4100c178f878:[0x4180267a3ec6]napi_poll+0xed stack: 0x4100c178f898
0x4100c178f938:[0x41802642abaf]WorldletBHHandler+0x426 stack: 0x417fe726c680
0x4100c178f9a8:[0x4180264218f7]BHCallHandlersInt+0x106 stack: 0x4100c178f9f8
0x4100c178f9f8:[0x418026421dc1]BH_Check+0x144 stack: 0x4100c178fae0
0x4100c178fa28:[0x41802642e524]IDT_HandleInterrupt+0x12b stack: 0x418040000000
0x4100c178fa48:[0x41802642e9f2]IDT_IntrHandler+0x91 stack: 0x0
0x4100c178fb28:[0x4180264a9b16]gate_entry+0x25 stack: 0x1

This issue is resolved in this release. The fix forces the NIC to a link-down state when the firmware synchronization times out, and thus prevents the ESX host from failing. The following message is written to the VMkernel log:

bnx2: Resetting... NIC initialization failed: vmnicX.
e1000e 1.1.2-NAPI driver added
In earlier releases, Intel e1000e 1.1.2-NAPI driver was not bundled with ESX but provided separately for download. In this release, e1000e 1.1.2-NAPI driver is bundled with ESX.
ESX hosts might fail with bnx2x
An ESX host with Broadcom bnx2x driver might exhibit the following symptoms:

The ESX host might lose network connectivity frequently.
The ESX host might stop responding with a purple diagnostic screen that displays messages similar to the following:
[0x41802834f9c0]bnx2x_rx_int@esx:nover: 0x184f stack: 0x580067b28, 0x417f80067b97, 0x
[0x418028361880]bnx2x_poll@esx:nover: 0x1cf stack: 0x417f80067c64, 0x4100bc410628, 0x
[0x41802825013a]napi_poll@esx:nover: 0x10d stack: 0x417fe8686478, 0x41000eac2b90, 0x4
The ESX host might stop responding with a purple diagnostic screen that displays messages similar to the following:
0:18:56:51.183 cu10:4106)0x417f80057838:[0x4180016e7793]PktContainerGetPkt@vmkernel:nover+0xde stack: 0x1
0:18:56:51.184 pu10:4106)0x417f80057868:[0x4180016e78d2]Pkt_SlabAlloc@vmkernel:nover+0x81 stack: 0x417f800578d8
0:18:56:51.184 cpu10:4106)0x417f80057888:[0x4180016e7acc]Pkt_AllocWithUseSizeNFlags@vmkernel:nover+0x17 stack: 0x417f800578b8
0:18:56:51.185 cpu10:4106)0x417f800578b8:[0x41800175aa9d]vmk_PktAllocWithFlags@vmkernel:nover+0x6c stack: 0x1
0:18:56:51.185 cpu10:4106)0x417f800578f8:[0x418001a63e45]vmklnx_dev_alloc_skb@esx:nover+0x9c stack: 0x4100aea1e988
0:18:56:51.185 cpu10:4106)0x417f80057918:[0x418001a423da]__netdev_alloc_skb@esx:nover+0x1d stack: 0x417f800579a8
0:18:56:51.186 cpu10:4106)0x417f80057b08:[0x418001b6c0cf]bnx2x_rx_int@esx:nover+0xf5e stack: 0x0
0:18:56:51.186 cpu10:4106)0x417f80057b48:[0x418001b7e880]bnx2x_poll@esx:nover+0x1cf stack: 0x417f80057c64
0:18:56:51.187 cpu10:4106)0x417f80057bc8:[0x418001a6513a]napi_poll@esx:nover+0x10d stack: 0x417fc1f0d078
The bnx2x driver or firmware sends panic messages and writes a backtrace with messages similar to the following in the /var/log/vmkernel log file:
vmkernel: 0:00:34:23.762 cpu8:4401)<3>[bnx2x_attn_int_deasserted3:3379(vmnic0)]MC assert!
vmkernel: 0:00:34:23.762 cpu8:4401)<3>[bnx2x_attn_int_deasserted3:3384(vmnic0)]driver assert
vmkernel: 0:00:34:23.762 cpu8:4401)<3>[bnx2x_panic_dump:634(vmnic0)]begin crash dump

ESX host fails with a purple diagnostic screen that displays a spin count exceeded error
A networking issue might cause an ESX host to fail with a purple diagnostic screen that displays an error message similar to the following:

Spin count exceeded (rentry) -possible deadlock with PCPU6

This issue occurs if the system is sending traffic and modifying the routing table at the same time.

This issue is resolved in this release.
NIC teaming policy does not work properly on legacy vSwitches
If you configure the port group policies of NIC teaming for parameters such as load balancing, network failover detection, notify switches, or failback, and then restart the ESX host, the ESX host might send traffic only through one physical NIC.

This issue is resolved in this release.
Cisco Discovery Protocol (CDP) network location information is missing on ESX hosts
The vSphere Client and the ESX command line utility might not display CDP network location information.

This issue is resolved in this release.
ESX hosts might not start or might cause some devices become inaccessible when using NetXen 1G NX3031 devices or multiple 10G NX2031 devices
When you install new NetXen NICs on an ESX 4.0 host or when you upgrade from ESX 3.5 to ESX 4.0, you might see an error message similar to the following on the service console of the ESX 4.0 host: Out of Interrupt vectors. On ESX hosts, where NetXen 1G and NX2031 10G devices do not support NetQueue, the ESX host might run out of MSI-X interrupt vectors. ESX hosts might not start or other devices (such as storage devices) might become inaccessible because of this issue.

The issue is resolved in this release.

Storage

Connecting to a tape library through an Adaptec card with aic79xx driver might cause ESX to fail †
If your ESX Server is connected to a tape library with an Adaptec HBA (for example: AHA-39320A) that uses the aic79xx driver, the server might fail when the driver tries to access a freed memory area. Such a condition is accompanied by an error message similar to:
Loop 1 frame=0x4100c059f950 ip=0x418030a936d9 cr2=0x0 cr3=0x400b9000.

This issue is resolved in this release.
When the storage processor of the HP MSA2012fc storage array is reset, critical alerts are erroneously issued †
Resetting the storage processor of the HP MSA2012fc storage array causes the ESX/ESXi native multipath driver (NMP) module to send alerts or critical entries to VMkernel logs. These alert messages indicate that the physical media has changed for the device. However, these messages do not apply to all LUN types. They are only critical for data LUNs but do not apply to management LUNs.

This issue is resolved in this release.
ESX host might fail with a purple diagnostic screen while mounting virtual CD-ROM drive from the server Remote Supervisor Adapter (RSA)

This issue is resolved in this release.
FalconStor IPStor failover results in APD (All Paths Down) state in ESX 4.x when using Qlogic FC HBAs
When performing an IPStor failover, messages similar to the following are logged in /var/log/vmkernel:

vmkernel: 1:10:57:57.524 cpu4:4219)<3>rport-4:0-0: blocked FC remote port time out: saving binding
vmkernel: 1:10:57:57.712 cpu2:4206)<3>rport-3:0-1: blocked FC remote port time out: saving binding

Qlogic has released an updated driver that is included with this release that addresses WWPN spoofing, the preferred method of FalconStor arrays for handling failover.
ESX host fails with a purple diagnostic screen when multiple processes access the same resource during Dentrycache initialization
This issue is resolved in this release.
ESX host logs messages in VMkernel log file when storage arrays are rescanned from vSphere Client
ESX hosts might log messages similar to the following in the VMkernel log file for LUNs not mapped to ESX hosts: 0:22:30:03.046 cpu8:4315)ScsiScan: 106: Path 'vmhba0:C0:T0:L0': Peripheral qualifier 0x1 not supported. The issue occurs when ESX hosts start, if you initiate a rescan operation of the storage arrays from the vSphere Client, or every 5 minutes after ESX hosts start.

This issue is resolved in this release.
ESX host fails to shut down if a SAN LUN encounters an All-Paths-Down (APD) state
When shutting down an ESX host, if a write-cache-enabled SAN LUN to which the ESX host has ever written becomes inaccessible, the ESX host fails to shut down and attempts perpetually to send the SYNC_CACHE command to the missing LUN.

This issue is resolved in this release.
Creation of large .vmdk files on NFS might fail
On NFS storage, attempts to create a virtual disk (.vmdk file) with a large size (for example, more than 1TB) might fail with the error A general system error occurred: Failed to create disk: Error creating disk. This issue occurs when the NFS client does not wait for sufficient time for the NFS storage array to initialize the virtual disk after the RPC parameter of the NFS client times out. By default the timeout value is 10 seconds.

This fix provides a configuration option. After applying this fix, you can make changes to the RPC timeout parameter by using the esxcfg-advcfg -s <Timeout> /NFS/SetAttrRPCTimeout command.
ESX host fails during LVM operations
If you perform operations that utilize the Logical Volume Manager (LVM) such as write operations, volume re-signature, volume span, or volume growth, the ESX host might fail with a purple diagnostic screen. Error messages similar to the following might be written to the logs:

63:05:21:52.692 cpu1:4135)OC: 941: Could not get object from FS driver: Permission denied
63:05:21:52.692 cpu1:4135)WARNING: Fil3: 1930: Failed to reserve volume f530 28 1 4be17337 9c7dae2 23004d45 22b547d 0 0 0 0 0 0 0
63:05:21:52.692 cpu1:4135)FSS: 666: Failed to get object f530 28 2 4be17337 9c7dae2 23004d45 22b547d 4 1 0 0 0 0 0 :Permission denied
63:05:21:52.706 cpu1:4135)WARNING: LVM: 2305: [naa.60060e80054402000000440200000908:1] Disk block size mismatch (actual 512 bytes, stored 0 bytes)

This issue is resolved in this release.
Some virtual machines stop responding during storage rescan operation when any LUN on the host is in an All-Paths-Down (APD) state
During storage rescan operations, some virtual machines stop responding when any LUN on the host is in an APD state. For more information, see KB 1016626. To work around the issue described in the KB article while using an earlier version of ESX host, you must manually set the advanced configuration option /VMFS3/FailVolumeOpenIfAPD to 1 before rescanning, and then reset it to 0 after completing the rescan.

This issue is resolved in this release. Now you need not apply the workaround of setting and resetting the advanced configuration option while starting the rescan operation. Virtual machines on non-APD volumes do not fail during a rescan operation, even if some LUNs are in an all-paths-down state.
ESX host fails with an error stating that spin count is exceeded
An ESX host connected to an NFS datastore might fail with a purple diagnostic screen that displays error messages similar to the following:

0x4100c00875f8:[0x41801d228ac8]ProcessReply+0x223 stack: 0x4100c008761c
0x4100c0087648:[0x41801d18163c]vmk_receive_rpc_callback+0x327 stack: 0x4100c0087678
0x4100c0087678:[0x41801d228141]RPCReceiveCallback+0x60 stack: 0x4100a00ac940
0x4100c00876b8:[0x41801d174b93]sowakeup+0x10e stack: 0x4100a004b510
0x4100c00877d8:[0x41801d167be6]tcp_input+0x24b1 stack: 0x1
0x4100c00878d8:[0x41801d16097d]ip_input+0xb24 stack: 0x4100a05b9e00
0x4100c0087918:[0x41801d14bd56]ether_demux+0x25d stack: 0x4100a05b9e00
0x4100c0087948:[0x41801d14c0e7]ether_input+0x2a6 stack: 0x2336
0x4100c0087978:[0x41801d17df3d]recv_callback+0xe8 stack: 0x4100c0087a58
0x4100c0087a08:[0x41801d141abc]TcpipRxDataCB+0x2d7 stack: 0x41000f03ae80
0x4100c0087a28:[0x41801d13fcc1]TcpipRxDispatch+0x20 stack: 0x4100c0087a58

This issue might occur due to a corrupted response received from the NFS server for any read operation that you perform on the NFS datastore.

This issue is resolved in this release.
ESX host fails when VMFS snapshot volumes are exposed to multiple hosts in a vCenter Server cluster
An ESX host might fail with a purple diagnostic screen that displays an error message similar to the following when VMFS snapshot volumes are exposed to multiple hosts in a vCenter Server cluster.

WARNING: LVM: 8703: arrIdx (1024) out of bounds

This issue is resolved in this release.
ESX host fails due to megaraid_sas driver issue
When an I/O failure occurs in the megaraid_sas driver because of a device error, the sense buffer is not filled properly. This causes the ESX host to fail.
ESX host fails while performing certain virtual machine operations during storage LUN path failover
During storage LUN path failover, if you perform any virtual machine operation that causes delta disk metadata updates such as create or delete snapshots, the ESX host might fail with a purple diagnostic screen.

This issue is resolved in this release.
Error messages logged when scanning for LUNs from iSCSI storage array
ESX hosts might fail and display a NOT_REACHED bora/modules/vmkernel/tcpip2/freebsd/sys/support/vmk_iscsi.c:648 message on a purple screen when you scan for LUNs from iSCSI storage array by using the esxcfg-swiscsi command from the service console or through vSphere Client (Inventory > Configuration > Storage Adapters > iSCSI Software Adapter). This issue might occur if you manually modify the tcp.window.size parameter in /etc/vmware/vmkiscsid/iscsid.conf file.

This release resolves the issue and also logs warning messages in /var/log/vmkiscsid.log file for ESX if you modify the tcp.window.size parameter to a value lower than its default.
ESX host with software iSCSI initiator fails displaying iscsi_vmk messages
ESX hosts that are using software iSCSI initiators might fail with a purple diagnostic screen that displays iscsi_vmk messages similar to the following:

#PF Exception(14) in world 4254:iscsi_trans_ ip 0x41800965fddb addr 0x8
Code starts at 0x418009000000
0x4100c04f7e50:[0x41800965fddb]iscsivmk_ConnShutdown+0x486 stack: 0x410000000000
0x4100c04f7eb0:[0x418009665e93]iscsivmk_StopConnection+0x286 stack: 0x4100c04f7ef0
0x4100c04f7ef0:[0x418009663e4c]iscsivmk_TransportStopConn+0x12b stack: 0x4100c04f7f6c
0x4100c04f7fa0:[0x418009481654]iscsitrans_VmklinkTxWorld+0x36f stack: 0x1d
0x4100c04f7ff0:[0x41800909870b]vmkWorldFunc+0x52 stack: 0x0
0x4100c04f7ff8:[0x0]Unknown stack: 0x0

This issue occurs when I/O delays cause I/O requests to time out and cancel.

This issue is resolved in this release.
Snapshots of upgraded VMFS volumes fail to mount on ESX 4.x hosts
Snapshots of VMFS3 volumes upgraded from VMFS2 with block size greater than 1MB might fail to mount on ESX 4.x hosts. The esxcfg-volume -l command to list the detected VMFS snapshot volumes fail with the following error message:

~ # esxcfg-volume -l
Error: No filesystem on the device

This issue is resolved in this release. Now you can mount or re-signature snapshots of VMFS3 volumes upgraded from VMFS2.
ESX host fails with Found invalid object error

An ESX host might fail with a purple diagnostic screen that displays error messages similar to the following:

[7m21:04:02:05.579 cpu10:4119)WARNING: Fil3: 10730: Found invalid object on 4a818bab-b4240ea4-5b2f-00237de12408 expected
21:04:02:05.579 cpu10:4119)FSS: 662: Failed to get object f530 28 2 4a818bab b4240ea4 23005b2f 824e17d 4 1 0 0 0 0 0 :Not found
21:04:02:05.579 cpu0:4096)VMNIX: VMKFS: 2521: status = -2

This issue occurs when a VMFS volume has a corrupt address in the file descriptor.

This issue is resolved in this release.
Rescan operations take a long time or times out with read-only VMFS volume

Rescan or add-storage operations that you run from the vSphere Client might take a long time to complete or fail due a timeout, and messages similar to the following are written to /var/log/vmkernel:

Jul 15 07:09:30 [vmkernel_name]: 29:18:55:59.297 <cpu id>ScsiDeviceToken: 293: Sync IO 0x2a to device "naa.60060480000190101672533030334542" failed: I/O error H:0x0 D:0x2 P:0x0 Valid sense data: 0x7 0x27 0x0.
Jul 15 07:09:30 [vmkernel name]: 29:18:55:59.298 cpu29:4356)NMP: nmp_CompleteCommandForPath: Command 0x2a (0x4100b20eb140) to NMP device "naa.60060480000190101672533030334542" failed on physical path "vmhba1:C0:T0:L100" H:0x0 D:0x2 P:0x0 Valid sense data: 0x7 0x27 0x0.
Jul 15 07:09:30 [vmkernel_name]: 29:18:55:59.298 cpu29:4356)ScsiDeviceIO: 747: Command 0x2a to device "naa.60060480000190101672533030334542" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x7 0x27 0x0.

VMFS continues trying to mount the volume even if the LUN is read-only.

This issue is resolved in this release. From this release, VMFS does not attempt to mount the volume when it receives the read-only status.
Target information for some LUNs is missing in the vCenter Server UI
Target information for LUNs is sometimes not displayed in the vCenter Server UI. To view this information in the Configuration tab, perform the following steps:
1. Click Storage Adapters under Hardware.
2. Click iSCSI Host Bus Adapter in the Storage Adapters pane.
3. Click Paths in the Details pane.
ESX hosts using QLogic HBAs become unresponsive due to heap memory depletion
When using QLogic HBAs, ESX 4.x hosts might become unresponsive due to heap memory depletion. The hosts are disconnected in vCenter Server and are inaccessible through SSH or vSphere Client. Error messages similar to the following are written to the VMkernel log:

vmkernel: 17:12:38:35.647 cpu14:6799)WARNING: Heap: 1435: Heap qla2xxx already at its maximumSize. Cannot expand.
vmkernel: 17:12:38:35.647 cpu14:6799)WARNING: Heap: 1645: Heap_Align(qla2xxx, 96/96 bytes, 64 align) failed. caller: 0x418011ea149b

This issue is resolved in this release.
VMFS logs misleading error messages
VMFS volumes might log misleading error messages similar to following in the VMkernel log file, which indicate disk corruption instead of benign un initialized log buffer:

Aug 4 21:45:43 [host name] vmkernel: 114:02:53:33.345 cpu9:21627)FS3: 3833: FS3DiskLock for [type bb9c7cd0 offset 13516784692132593920 v 13514140778984636416, hb offset 16640
Aug 4 21:45:43 [host name] vmkernel: gen 0, mode 16640, owner 00000006-4cd3bbfe-fece-e61f133cdd37 mtime 35821792] failed at 60866560 on volume [volume name]

This issue is resolved in this release.
Connecting certain USB storage devices might cause an ESX host to fail
Connecting certain USB storage devices might cause an ESX host to fail with a purple screen and display an error message similar to the following: @BlueScreen: #UD Exception(6) in world 1037009:usb-storage @ 0x41803a844eb6 Code starts at 0x41803a400000 0x4100c168fe90:[0x41803a844eb6]usb_stor_invoke_transport+0x73d stack: 0x10 0x4100c168feb0:[0x41803a842158]usb_stor_transparent_scsi_command+0x1b stack: 0x7d41af17b64564 0x4100c168ff30:[0x41803a8467b9]usb_stor_control_thread+0x7c4 stack: 0x4100b0fdbaa0 0x4100c168ff60:[0x41803a7c51f2]kthread+0x79 stack: 0x41000000000e 0x4100c168ffa0:[0x41803a7c2b62]LinuxStartFunc+0x51 stack: 0xe 0x4100c168fff0:[0x41803a49870b]vmkWorldFunc+0x52 stack: 0x0

ESX now detects these protocol violations and handles them.
ESX host becomes unresponsive if one of the mirrored installation drives is removed from the server
An ESX host might become unresponsive if you unexpectedly remove one of the mirrored installation drives from the server that is connected to an LSI SAS controller. The ESX console shows messages similar to the following:

[329125.915302] sd 0:0:0:0: still retrying 0 after 360 s [329175.056594] sd 0:0:0:0: still retrying 0 after 360 s [329226.201904] sd 0:0:0:0: still retrying 0 after 360 s [329276.339208] sd 0:0:0:0: still retrying 0 after 360 s [329326.478513] sd 0:0:0:0: still retrying 0 after 360 s

This issue is resolved in this release.
Under certain conditions the QLogic iSCSI HBA driver might block interrupts for a long time and cause an ESX host to fail displaying a purple screen

This issue is resolved in this release.
ESX host fails with a purple screen and displays a Unhandled Async_Token ENOMEM Condition error
Due to memory allocation failure on a system that is under memory constraints when allocating Async_Token for handling I/O, the ESX host fails.

This release minimizes the occurrence of this issue.

Upgrade and Installation

Cannot revert to snapshots created on ESX 3.5 hosts

ESX hosts cannot revert to a previous snapshot after you upgrade from ESX 3.5 Update 4 to ESX 4.0 Update 3. The following message might be displayed in vCenter Server when you attempt such an operation: The features supported by the processor(s) in this machine are different from the features supported by the processor(s) in the machine on which the checkpoint was saved. Please try to resume the snapshot on a machine where the processors have the same features. This issue might occur when you create virtual machines on ESX 3.0 hosts, perform vMotion and suspend virtual machines on ESX 3.5 hosts, and resume them on ESX 4.x hosts.

In this release, the error message does not appear. You can revert to snapshots created on ESX 3.5 hosts, and resume the virtual machines on ESX 4.x hosts.
ESX host restart fails due to missing descriptor file
An ESX host fails to restart when it cannot identify the esxconsole.vmdk file in which the service console resides.

This issue is resolved in this release.
This release provides an updated version of PVSCSI driver which enables you to install Windows XP guest operating system

Virtual Machine Management

Devices that are not hot-removable from the vSphere Client can be removed on a Fault Tolerance-enabled virtual machine
When Fault Tolerance is enabled, you should not be able to hot-remove devices such as NICs and SCSI controllers from the vSphere Client. However, these appear as removable devices in the Windows system tray of the virtual machine and you can remove them from within the guest operating system.

This issue is resolved in this release. Now you cannot remove devices from the virtual machine's system tray when Fault Tolerance is enabled.
Snapshot delta files are not deleted when snapshots are created in a custom directory
All snapshots are created in a default virtual machine directory. However, if you specify a custom directory for snapshots, snapshot delta files might remain in this directory when you delete snapshots. These redundant files eventually fill up disk space and should be deleted manually.

This issue is resolved in this release.
Stopping VMware Tools while taking a quiesced snapshot of a virtual machine causes hostd to fail
This issue is resolved in this release. Now the quiesced snapshot operation fails gracefully if you stop VMware Tools.
Virtual machines fail to power on in some cases even when swap space exists on ESX hosts
When you power on virtual machines running on an ESX host, the operation fails and logs an Insufficient COS swap to power on error message in the /var/log/vmware/hostd.log file even though service console has 800MB of free space and is swap enabled. Also, running the free -m command on the service console shows more than 20MB free space. After installing this update, you can power on virtual machines when the swap space exists on ESX hosts.
ESX host might become unresponsive during a RevertSnapshot or RevertToCurrentSnapshot operation
An ESX host might become unresponsive when you perform a RevertSnapshot or RevertToCurrentSnapshot operation from the vCenter Server. The following error message is logged in hostd.log:

Apr 22 08:46:26 Hostd: [2010-04-22 08:46:26.381 'App' 49156 error] Caught signal 11

This issue is resolved in this release.
Virtual machine fails during vMotion
If the NFS volume hosting a virtual machine encounters errors, the NVRAM file of the virtual machine might become corrupted and grow in size from the default 8KB up to a few gigabytes. At this time, if you perform a vMotion or a suspend operation, the virtual machine fails displaying an error message similar to the following:

unrecoverable memory allocation failures at bora/lib/snapshot/snapshotUtil.c:856

This issue is resolved in this release.
Virtual machine commands fail when run in hostd console immediately after a virtual machine powers off

A virtual machine command such as PowerOn that you run by using a hostd console immediately after a virtual machine powers off might fail with an error message similar to the following:

A specified parameter was not correct

The vCenter log file might contain an error message similar to the following:

[2009-11-16 15:06:09.266 01756 error 'App'] [vm.powerOn] Received unexpected exception

This issue is resolved in this release.
Virtual machines configured with CPU limits running on ESX 4.x hosts experience performance degradation (KB 1030955)
Virtual machine sometimes powers off while creating or deleting snapshots
While performing snapshot operations, if you simultaneously perform another task such as browsing a datastore, the virtual machine might be abruptly powered off. Error messages similar to the following are written to vmware.log:

vmx| [msg.disk.configureDiskError] Reason: Failed to lock the file
vmx| Msg_Post: Error
vmx| [msg.checkpoint.continuesync.fail] Error encountered while restarting virtual machine after taking snapshot. The virtual machine will be powered off.

This issue occurs when another process accesses the same file that is required by the virtual machine for one operation.

This issue is resolved in this release.
Committing a snapshot from the command line fails with a backtrace
When running the vmware-cmd <vmx> removesnapshots command, you might see a backtrace similar to the following:

Traceback (most recent call last):
File "/usr/bin/vmware-cmd", line 88, in ?
main()
File "/usr/bin/vmware-cmd", line 63, in main
operationName, result = CommandProcessor.Process(host, args)
File "/usr/lib/vmware/vmware-cmd/CommandProcessor.py", line 11, in Process
result = operation.DoIt(*processedArgs)
File "/usr/lib/vmware/vmware-cmd/operations/SnapshotOps.py", line 122, in DoIt

The vmware-cmd <vmx> removesnapshots command fails because the <vm_name>-aux.xml file located in the same directory as the virtual machine configuration file is empty. When a virtual machine is created or registered on a host, the contents of the <vm_name>-aux.xml file is read and the _view object is populated. If the XML file is empty the _view object is not populated. This results in an error when consolidating the snapshot.

This issue is resolved in this release.
Memory hot-add fails if the assigned virtual machine memory equals the size of its memory reservation
An error message similar to the following appears in the vSphere Client:

Hot-add of memory failed. Failed to resume destination VM: Bad parameter. Hotplug operation failed

Messages similar to the following are written to the /var/log/vmkernel log file:

WARNING: FSR: 2804: 1270734344 D: Received invalid swap bitmap lengths: source 0, destination 32768! Failing migration.
WARNING: FSR: 3425: 1270734344 D: Failed to transfer swap state from source VM: Bad parameter
WARNING: FSR: 4006: 1270734344 D: Failed to transfer the swap file from source VM to destination VM.

This issue occurs if Fast Suspend Resume (FSR) fails during the hot-add operation.

This issue is resolved in this release.

vMotion and Storage vMotion

vMotion fails due to problems with NSCD
A vMotion operation might fail if the NSCD (Linux Name Server Cache Daemon) that runs in the service console cannot resolve the FQDN and LDAP names.

This issue is resolved in this release.
ESX hosts might fail when storage vMotion operation is cancelled when you are relocating a powered on virtual machine
Canceling a storage vMotion operation when relocating a powered-on virtual machine that contains multiple disks on the same datastore to a different datastore on the same host might cause the ESX 4.0 host to fail with the following error message: Exception: NOT_IMPLEMENTED bora/lib/pollDefault/pollDefault.c:2059.

The issue is resolved in this release.

VMware Tools

Perfmon does not list virtual machine performance counters after VMware Tools installation
After you install VMware Tools, VM Memory and VM Processor might not appear in the performance counters list in the Windows Performance Monitor (Perfmon) when another process accesses the file that is required by the virtual machine for an operation. Performing an upgrade or repair of VMware Tools does not resolve this problem.

After you install this update release, you can upgrade or repair VMware Tools to resolve the issue.
Creation of quiesced snapshots might not work on non-English versions of Microsoft Windows guest operating systems
The issue occurs when a Windows folder path contains non-ASCII characters (for example, in the case of the application-data folder in Czech Windows guest operating systems). The presence of non-ASCII characters causes the snapshot operation to fail.

This issue is resolved in this release.
VMware Control Panel UI button in Windows Control Panel is disabled for performing VMware Tools upgrade
The VMware Control Panel UI button in Windows Control Panel for performing VMware Tools upgrade from a Windows guest operating system is disabled for non-administrator users. Also, Shrink and Scripts options in the VMware Tools Control Panel are disabled for non-administrator users. This fix is only a UI change and does not block upgrades from custom applications. To block VMware Tools upgrades for all users, you must set the isolation.tools.autoinstall.disable="TRUE" parameter in the VMX file.
Configuration file entries are overwritten on Linux virtual machines while installing VMware Tools

When you install or update VMware Tools on Linux virtual machines, the VMware Tools installer might overwrite any entries in the configuration files (such as in /etc/updatedb.conf file for Redhat and Ubuntu, and in /etc/sysconfig/locate for SuSE) made by third-party development tools. This might affect cron jobs running updatedb on these virtual machines.

This issue is resolved in this release.
Creation of quiesced snapshots might fail on some non-English versions of Windows guest operating systems
Quiesced snapshots might fail on some non-English versions of Windows guest operating systems, such as French versions of Microsoft Windows Server 2008 R2 and Microsoft Windows 7 guest operating systems. This issue occurs because the VMware Snapshot Provider service is not registered as a Windows service or as a COM+ application on some non-English versions of Microsoft Windows guest operating systems. This issue causes the snapshot operation to fail, and as a result, no snapshot is created.

This issue is resolved in this release.
Device Manager reports extraneous errors when restarting Linux virtual machines after installing VMware Tools
After you install VMware Tools for Linux and restart the guest operating system, the device manager for the Linux kernel (udev) might report extraneous errors similar to the following:

May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'SUBSYSTEMS'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{vendor}'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{model}'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'SUBSYSTEMS'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{vendor}'
May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'AT

This issue is resolved in this release. Now the VMware Tools Installer for Linux detects the device and only writes system-specific rules.
Windows virtual machine loses network connectivity after upgrading VMware Tools
When you upgrade VMware Tools with Host Guest File System (HGFS) installed from ESX 3.5 to ESX 4.0, the HGFS driver might not be uninstalled properly. As a result, the Windows virtual machine's network Provider Order tab under Network Connections > Advanced > Advanced Settings displays incorrect information, and the virtual machine might lose network connectivity.

This issue is resolved in this release. Now the earlier version of the HGFS driver and all related registry entries are uninstalled properly during upgrade.
Updates PVSCSI driver

In this release, the PVSCSI driver is updated to version 1.0.7.0 for Windows XP (32/64-bit), Windows Server 2003 (32/64-bit), Windows Vista (32/64-bit), Windows Server 2008 RTM (32/64-bit), Windows 7 (32/64-bit), and Windows Server 2008 R2 (64-bit) guest operating systems.
Certain guest operating systems encounter unsolved symbol __stack error when you are installing VMware Tools
While installing VMware Tools on certain guest operating systems such as RHEL 3, you might see an error message similar to the following:

Symbol __stack_chk_fail from module /usr/X11R6/lib/modules/drivers/vmware_drv.o is unresolved!

This issue is resolved in this release.
Automatic VMware Tools upgrade does not work if hardware acceleration is set to None on a Windows virtual machine
If hardware acceleration is set to None on a Windows virtual machine, even if you configure it with the Check and upgrade Tools before each power-on option, VMware Tools is not upgraded immediately after you restart the virtual machine. VMware Tools is upgraded only when you respond to the hardware acceleration dialog box that the virtual machine displays after you log in.

This issue is resolved in this release.

Top of Page

Known Issues

This section describes known issues in this release in the following subject areas:

Backup
CIM and API
Guest Operating Systems
Internationalization
Licensing
Miscellaneous
Networking
Server Configuration
Storage
Supported Hardware
Upgrade and Installation
vCenter Server, vSphere Client, and vSphere Web Access
Virtual Machine Management
vMotion and Storage vMotion
VMware HA and Fault Tolerance
VMware Tools

Known issues not previously documented are marked with the * symbol.

Backup

VMware Consolidated Backup (VCB) 1.5 Update 1 with Windows 7 and Windows 2008 R2 x64
VMware Consolidated Backup (VCB) 1.5 Update 1 supports full virtual machine backup and restore of Windows 7 and Windows 2008 R2 x64 guest operating systems. However, file level backup is not supported on Windows 7 or Windows 2008 R2 x64 guest operating systems.

VMware Consolidated Backup (VCB) is not supported with Fault Tolerance
A VCB backup performed on an FT-enabled virtual machine powers off both the primary and the secondary virtual machines and might render the virtual machines unusable.
Workaround: None

CIM and API

Some power supply VRM sensors are not displayed in vCenter Hardware status tab for IBM x3850 and x3950 M2 servers *
In vCenter Server Hardware status tab, sensors are not displayed for all the states of PS VRM sensor in the Hardware status tab for IBM x3850 and x3950 M2 servers. The CIM instances are not created corresponding to each state of the Power Supply VRM sensor on IBM x3850 and x3950 M2 servers. This is due to a defect in the IBM BMC firmware 4.5. Hence, the sensors are not displayed in vCenter Hardware status tab.

Incorrect version number listed in Small Footprint CIM Broker *
The Small Footprint CIM Broker version listed from SLP service is incorrect. This release contains SFCB 1.3.3 version, but in the SLP query information, the version is listed as 1.3.0. This incorrect version number does not impact the usage of SLP service. Currently, there is no workaround for this issue.

CIM Indication subscription is lost after an ESX update *
CIM Indication subscription is lost when upgrading between ESX updates or when applying patches. The information regarding where to send the indication is overwritten by the upgrade and, therefore, lost.

Workarounds: Either of the following workarounds can be effective. Employ the method that best suits your deployment.
- Re subscribe the CIM indications
  You might not be able to employ this workaround. Sometimes re subscribing the CIM indications is not an option.
- Copy the appropriate files from the backup repository to the new repository as described in the sub steps that follow.
  This workaround recovers the CIM XML indication subscriptions.
  1. Move the following files from the back up repository to the new repository: cim_indicationfilter cim_indicationfilter.idx cim_indicationhandlercimxml cim_indicationhandlercimxml.idx cim_indicationsubscription cim_indicationsubscription.idx cim_listenerdestinationcimxml cim_listenerdestinationcimxml.idx.
    For example, move the preceding files from the backup repository, such as /var/lib/sfcb/registration/repository.previous/root/interop, to the new repository, such as
    /var/lib/sfcb/registration/repository/root/interop
  2. Restart the sfcbd-watchdog process.

Guest Operating System

Debian 5 virtual machine displays error during snapshot operation (KB 1037897) *
Windows Server 2008 R2 virtual machine with VMXNET 3 driver fails (KB 1037894) *
Removing the disk from a virtual machine with a RHEL3 guest operating system without informing the guest causes the virtual machine to fail
For a 32-bit virtual machine with a RHEL3 guest operating system and a BusLogic driver, hot removing the disk without informing the guest OS about the disk removal causes the virtual machine operation to fail.
Workaround: Remove the disk from the guest explicitly. To remove the disk, first get the disk details from /proc/scsi/scsi for the disk that you want to remove:
1. Get the HOST CHAN ID and LUN numbers for the device from /proc/scsi/scsi
2. Run the following command in the RHEL console:
  echo "scsi remove-single-device HOST CHAN DEV LUN" > /proc/scsi/scsi

Solaris 10 U4 virtual machine becomes non responsive during VMware Tools upgrade
Upgrading or restarting VMware Tools in a Solaris 10 U4 virtual machine with an advanced vmxnet adapter might cause the guest operating system to become non responsive and the installation to be unable to proceed.
Solaris 10 U5 and later versions are not affected by this issue.

Workaround: Before installing or upgrading VMware Tools, temporarily reconfigure the advanced vmxnet adapter by removing its auto configuration files in /etc/ or removing the virtual hardware.

Devices attached to hot-added BusLogic adapter are not visible to Linux guest
Devices attached to hot-added BusLogic adapter are not visible to a Linux guest if the guest previously had another BusLogic adapter. In addition, hot removal of the BusLogic adapter might fail. This issue occurs because the BusLogic driver available in Linux distributions does not support hot plug APIs. This problem does not affect performing hot add of disks to the adapter, only performing hot add of the adapter itself.
Workaround: Use a different adapter, such as a parallel or SAS LSI Logic adapter, for hot add capabilities. If a BusLogic adapter is required, attempt a hot remove of the adapter after unloading the BusLogic driver in the guest. You can also attempt to get control of the hot-added adapter by loading another instance of the BusLogic driver. You can load another instance of the BusLogic adapter by running the command modprobe -o BusLogic1 BusLogic (where you replace BusLogic1 with BusLogic2, BusLogic3 for BusLogic2, and so on, for every hot add operation).

Virtual machines with Windows NT guest operating systems require a response to a warning message generated when the virtual machine attempts to automatically upgrade VMware Tools
If you set the option to automatically check and upgrade VMware Tools before each power-on operation for WindowsNT guests, the following warning message appears:
Set up failed to install the vmxnet driver Automatically, This driver will have to be installed manually

Workaround: The upgrade stops until the warning is acknowledged. To complete the upgrade, log into the WindowsNT guest and acknowledge the warning message.

Creating a virtual machine of Ubuntu 7.10 Desktop can result in the display of a black screen
When you run the installation for the Ubuntu 7.10 Desktop guest on a virtual machine with paravirtualization enabled on an AMD host, the screen of the virtual machine might remain blank. The correct behavior is for the installer to provide instructions for you to remove the CD from the tray and press return.

Workaround: Press the return key. The installation proceeds to reboot the virtual machine. Furthermore, this issue does not occur if you start the installation on a virtual machine with two or more virtual processors.

An automatic VMware Tools upgrade might fail for a Red Hat Enterprise Linux 5.x virtual machine
An automatic VMware Tools upgrade might fail with the Error upgrading VMware Tools error for a Red Hat Enterprise Linux 5.x virtual machine cold migrated from an ESX 3.0.3 host to an ESX/ESXi 4.0 Update 1 host.

Workaround: Manually upgrade VMware Tools on the ESX 4.0 Update 1 host.

Installation of Microsoft SQL Server 2005 or 2008 fails on virtual machines running Windows Server 2008 R2 that are configured in a Microsoft Cluster (KB 1021946)

Internationalization

Parallel/serial port output file name does not accept non-ASCII characters and displays an error message
When configuring a virtual machine, filenames that include non-ASCII characters might be rejected with an error message. The validation for filenames is not localization-safe and might result in rejection of a valid name. This problem affects output files for serial and parallel ports, and it might affect ISO and FLP names or disk (VMDK) filenames.
Workaround: Restrict all datastore contents (directories and filenames) to ASCII.

Licensing

A host with a single server license that fails to be added to vCenter Server is not given the option to correct licensing during a subsequent add host operation
When an ESX or ESXi host configured with a single server license is added to a licensed vCenter server, vCenter Server displays an error message explaining that the host cannot be added.
Workaround: Remove the disconnected host, and add it again with a non-single server license.

Virtual machines cannot power on if certain licenses are installed during a scripted or interactive installation
If you do not have the correct license serial numbers for your hardware, when you install ESX/ESXi, you might encounter a licensing error. This problem is seen because the vendor and resource check validation of license keys is not performed during the installation. After a license is validated with lib/licensecheck, a subsequent test is needed to check that the system installed is within the limits imposed by the license. However, the installer does not perform this second check.
Workaround: Switch to evaluation mode, and then get the appropriate license from the portal.

Purchased add-on licenses are not displayed in the License list on the vSphere Client Licensing page
When you view your purchased licenses on the vSphere Client Licensing page, a separate product line item for add-on editions is not displayed. For example, if you purchased a vSphere 4.0 Standard with vMotion license, or a vSphere 4.0 Standard with vMotion and Data Recovery license, only the vSphere 4.0 Standard license appears.
Workaround: To view the product features and add-on features for a license key, follow these steps:
1. On the vSphere Home page, click Licensing.
2. In the upper-right corner, click Manage vSphere Licenses to launch the License wizard.
3. Click Next to go to the Assign Licenses page.
4. Move your cursor over the host license key to see the available product and add-on features.

Miscellaneous

User-created files in the ESX /tmp directory are deleted with each host reboot
If you or the users you support store temporary files, such as application-generated log files, in the ESX /tmp directory, you will lose these files each time the host reboots.
Workaround: Do not use the ESX /tmp directory to store user-generated files and directories.

Diagnostic data from vCenter might be contained in file that cannot be decompressed
While extracting a .tgz file that contains diagnostic data from vCenter, a dialog lists files that cannot be extracted, as well as an error message:
Symbolic link points to missing files.

Workaround: None

The Linux rm -rf command might fail in service console
If you run rm -rf on a directory with more than 380 files, the command fails with the following error:
Directory not empty.

This problem is the result of a limitation in the Red Hat 2.6 kernel.

Workaround: Perform one of these tasks:
- Delete the directories by using the vSphere Client datastore browser.
- Run rm -rf multiple times, until all the entries are deleted. Each invocation of rm -rf deletes at most 380 entries.

ESX hosts with a TLS LDAP configuration do not allow LDAP users to login
ESX administrators can use the service console to follow LDAP with TLS authentication by running the following command:

esxcfg-auth --enableldap --enableldapauth --enableldaptls --ldapserver=<Server IP/Name> --ldapbasedn="dc=<LDAP DC Name>"

After authentication is turned on, you can no longer log in to the ESX host with an LDAP user name. Also, you cannot specify the location of the /etc/openldap/cacerts/client.pem certificate file from the command line.
Workaround: Perform the following steps:
1. Open the /etc/ldap.conf file in an editor, add the following, and save the file:
  
  URI ldaps://linux-ldaptls/
2. Open the /etc/openldap/ldap.conf file in an editor, add the following, and save the file:
  
  URI ldaps://linux-ldaptls/ TLS_CACERT /etc/openldap/cacerts/client.pem BASE dc=ns,dc=suchi,dc=com

ESX/ESXi host's core dump partition setting is not persistent under certain conditions
If you change the core dump partition from /root to a second location and experience an ESX/ESXi host failure within an hour after this change is made but before the host is rebooted, the core dump partition reverts to its original setting of /root.
Workaround: After changing the core dump partition, immediately run esxcfg-boot.

Warning message related to Execute Disable/No Execute CPU feature received on local console
The warning message The Execute Disable/No Execute CPU feature is not enabled for this machine appears on the local console when ESX 4.0 is installed on either an HP system with the No-Execute Memory Protection option disabled in the machine's system BIOS or on a Dell system with the Execute Disable option disabled in the machine's system BIOS.
Workaround: Enable the No-Execute Memory Protection or Execute Disable option in the HP or Dell machine's system BIOS respectively.

Stopping or restarting the vCenter Server service through the Windows Services Control MMC plug-in might lead to an error message
Under certain circumstances, the vCenter Server service might take longer than usual to start. Stopping and restarting the vCenter Server service through the Windows Services Control MMC plug-in might lead to the following error message:
Service failed to respond in a timely manner.

This message indicates that the time required to shut down or start up vCenter Server was more than the configured system-wide default timeout for starting or stopping the service.

Workaround: Refresh the Services Control screen after a few minutes, which should show that the service has been correctly stopped and restarted.

Networking

Removing an ESX/ESXi host configured with a vDS from a vCenter Server system results in inconsistent networking state on the host
If you remove an ESX/ESXi host configured with a vDS from a vCenter Server system, the host cannot reconnect to the vDS. When you add the host back to the vCenter Server system, a warning similar to the following appears:

The distributed Virtual Switch corresponding to the proxy switches d5 6e 22 50 dd f2 94 7b-a6 1f b2 c2 e6 aa 0f bf on the host does not exist in vCenter or does not contain the host.

The virtual machines continue to function on their respective ports, but new virtual machines are not allowed to power on. You cannot modify the vDS settings for this host by using a vSphere Client connected to the vCenter Server system.
Workaround: Perform the following steps:
1. Use a vSphere Client to connect directly to the ESX/ESXi host. This workaround requires a direct connection.
2. Migrate the virtual machines off of the invalid vDS ports one by one by editing the settings of each virtual machine. This will result in prolonged network interruption to the virtual machines.
3. Choose Host > Configuration > Networking > Distributed Virtual Switch and click Remove.
4. In a vSphere Client connected to the vCenter Server system, refresh the network settings of the host. The errors are cleared.
5. Add the host back to the vDS, either manually or by using a host profile.
6. Migrate the virtual machines back to their respective ports or port groups on the vDS. To do so, right-click the vDS and choose Migrate Virtual Machine Networking. This process also results in network interruption to the virtual machines.

VLAN tagging does not work in SLES10 guest operating systems when Oplin NIC is used in pass through mode (FPT)
This issue occurs when an Oplin 10GB adapter is assigned to a virtual machine running the SUSE Enterprise Linux 10 (SLES10) 32-bit or 64-bit guest operating system as an FPT (fixed pass through) device and the guest operating system is configured to perform VLAN tagging. In such a case, TCP traffic deteriorates and a call to netperf terminates prematurely with an error message. ICMP traffic still goes through and you can ping.
Workaround: Run tcpdump while the TCP traffic is active. Running tcpdump puts the NIC in promiscuous mode, which ensures that the traffic flows properly but consumes a high number of CPU cycles on the guest operating system.

For VMDirectPath Gen I, sharing a dual-function QLogic 2532 adapter between a virtual machine and either another virtual machine or the VMkernel might result in data corruption
When you configure a dual-function QLogic 2532 adapter for VMDirectPath IO, and assign the first PCI function to a virtual machine and the second to either the VMkernel or another virtual machine, data corruption might occur. This happens because both ports use the same credentials to log in to the fabric and have the same storage visibility. VMware does not support this configuration for VMDirectPath IO.
Workaround: If you cannot avoid sharing the dual-function adapter between a virtual machine and the VMkernel, assign the first PCI function to the virtual machine and the second to the VMkernel. The PCI functions cannot be split between two virtual machines.

ESX host disconnects when you remove the secondary service console if both vSwitches are in the same subnet
The host disconnects with an error message when you perform the following steps:
1. Add a secondary service console.
2. Change the gateway device of the service console.
3. Change the gateway device back to primary service console.
4. Remove the secondary service console.
Workaround: None

Foundry Edgeiron 8X10G switches might experience link status issues with Neterion NIC
If an active port on a Foundry Edgeiron 8X10G switch is repeatedly enabled and disabled over a long period of time, the toggling might force the port into a permanent state of link down.
Workaround: Reboot the switch or use a different switch port.

NetXen chipset does not have hardware support for VLANs
The NetXen NIC does not display Hardware Capability Support for VMNET_CAP_HW_TX_VLAN and VMNET_CAP_HW_RX_VLAN. This occurs because NetXen chipset does not have hardware support for VLANs. NetXen VLAN support is available in software.

The Custom creation of a virtual machine allows a maximum of four NICs to be added
During the creation of a virtual machine using the Custom option, vSphere Client provides the Network configuration screen. On that screen, you are queried about the number of NICs that you would like to connect. The drop down menu allows up to four NICs only. However, 10 NICs are supported on ESX/ESXi 4.0 Update 1.

Workaround: Add more NICs with the task that follows.

Using the vSphere Client, navigate to Home>Inventory>VMs and Templates.
With the Getting Started tab selected, click Edit virtual machine settings.
Click Add.
Select Ethernet Adapter and click Next.
Continue selecting the appropriate settings for your specific scenario.

Cannot assign addresses to the ESX service console port after reboot
If a service console port has neither IPv4/IPv6 static addresses configured nor any automatic methods of configuration (DHCP, DHCP6, or AUTOCONF) enabled, the port remains in an invalid state after reboot and you cannot assign addresses to this interface.
Workaround: Configure a static IP address (IPv4 or IPv6) or set up the service console port to use an automatic address generation method (such as DHCP, DHCP6, or AUTOCONF) before rebooting. You can also recreate the service console port after reboot.

The VmwVmNetNum of VM-INFO MIB displays as Ethernet0 when running snmpwalk
When snmpwalk is run for VM-INFO MIB on an ESX/ESXi host, the VmwVmNetNum of VM-INFO MIB is displayed as Ethernet0 instead of Network Adapter1 while the MOB URL in the VmwVmNetNum of VM-INFO description displays as Network Adapter1.
Workaround: None

Applications that use VMCI Sockets might fail after virtual machine migration
If you have applications that use Virtual Machine Communication Interface (VMCI) Sockets, the applications might fail after virtual machine migration if the VMCI context identifiers used by the application are already in use on the destination host. In this case, VMCI stream or Datagram sockets that were created on the originating host stop functioning properly. It also becomes impossible to create new stream sockets.
Workaround: For Windows guest operating systems, reload the guest VMCI driver by rebooting the guest operating system or enabling the device through the device manager. For Linux guests, shut down applications that use VMCI Sockets, remove and reload the vsock kernel module and restart the applications.

Applying port groups with multiple statically assigned VMKNICs or VSWIFs results in repeated prompts for an IP address
Applying a vDS port group with multiple statically assigned VMKNICs or VSWIFs causes a situation in which the user is repeatedly prompted to enter an IP address. DHCP assigned interfaces are not affected.
Workaround: Use only one statically assigned VMKNIC or VSWIF per port group. If multiple statically assigned VMKNICs are desired on the same vDS port group, then assign each VMKNIC or VSWIF to a unique set of services (for example, vMotion, Fault Tolerance, and other services).

The console for the guest operating system fails and you cannot access the guest through the console if you set MTU to less than 1500 for a vNetwork Distributed Switch or a vSwitch that has the service console port group or the management network port group
If you set the MTU for the vNetwork Distributed Switch or the vSwitch that includes the service console port group for ESX or the Management Network port group for ESXi Embedded to less than 1500, the console for the guest operating system fails and you cannot access the guest through the console. The service console port group for ESX and the management network port group for ESXi Embedded must be connected to a vSwitch or vNetwork Distributed Switch with an MTU set to 1500 or higher.
Workaround: Avoid setting the MTU value less than 1500 for the vNetwork Distributed Switch or the vSwitch that includes the service console port group for ESX or the management Network port group for ESXi Embedded.

The Retrieval of DNS and host name information from the DHCP server might be delayed or prevented

When ESX 3.5 hosts are upgraded to ESX 4.0 some of the network device load the e1000e driver instead of e1000 *
When ESX 3.5 Update 4 or ESX 3.5 Update 5 hosts are upgraded to ESX 4.0 or later, the following network devices have the e1000e driver loaded instead of e1000:
- Intel 82571EB Gigabit Ethernet Controller (including 105e, 105f, 1060, 10a4, 10a5, 10bc)
- Intel 82572EI Gigabit Ethernet Controller (including 107d, 107e, 107f, 10b9)
- Intel 82573V Gigabit Ethernet Controller (including 108b)
- Intel 82573E Gigabit Ethernet Controller (including 108c)
- Intel 80003ES2LAN Gigabit Ethernet Controller (including 1096, 1098, 10ba, 10bb)
- Intel 82573L Gigabit Ethernet Controller (including 109a)

Changing the network settings of an ESX/ESXi host prevents some hardware health monitoring software from auto-discovering it
After the network settings of an ESX/ESXi host are changed, the third-party management tool that relies on the CIM interface (typically hardware health monitoring tools) are unable to discover automatically the host through the Service Location Protocol (SLP) service.
Workaround: Manually enter the hostname or IP address of the host in the third-party management tool. Alternatively, restart slpd and sfcbd-watchdog by using the applicable method:
On ESXi:
1. Enter the Technical Support Mode.
2. Restart slpd by running the /etc/init.d/slpd restart command.
3. Restart sfcbd-watchdog by running the /etc/init.d/sfcbd-watchdog restart command.
Restart management agents on the Direct Console User Interface (DCUI). This restarts other agents on the host in addition to the ones impacted by this defect and might be more disruptive.
On ESX: In the ESX service console, run the following commands:
/etc/init.d/slpd restart
/etc/init.d/sfcbd-watchdog restart

Virtual Machines Lose Network Connectivity When Moved to ESX Host With Default Number of Ports
By default, the ESX service console is installed with a virtual switch with only 24 ports. When virtual machines are migrated to a host such that the number of ports required exceeds that default, some virtual machines might lose network connectivity. This issue can occur when virtual machines are moved manually, or during disaster recovery scenarios and migration with vMotion.

Workaround: After installation, modify vSwitch0 to have a larger number of ports by editing switch properties. ESX 4.0 and later support up to 56 ports on a virtual switch.

Server Configuration

Host profiles do not capture or duplicate physical NIC duplex information
When you create a new host profile, the physical NIC duplex information is not captured. This is the intended behavior. Therefore, when the reference host's profile is used to configure other hosts, the operation negotiates the duplex configuration on a per physical NIC basis. This provides you with the capability to generically handle hosts with a variety of physical NIC capabilities.
Workaround: To set the physical NIC duplex value uniformly across NICs and hosts that are to be configured using the reference host profile, modify the host profile after it is created and reapply the parameters.

To edit the profile, follow the steps below.
1. On the vSphere Client Home page, click Host Profiles.
2. Select the host profile in the inventory list, then click the Summary tab and click Edit Profile.
3. Select Network configuration > Physical NIC configuration > Edit.
4. Select Fixed physical NIC configuration in the drop-down menu and enter the speed and duplex information.

On ESX, no error results if net-snmp and hostd SNMP agent are configured to run on same port
If you assign the VMware SNMP daemon (hostd) to the same UDP port as the SNMP daemon (snmpd), no error results, but later access of SNMP functionality shows the following symptoms:
- If net-snmp opens UDP/161 first, and attempt to run snmpwalk for VMware enterprise MIB objects under enterprise.6876, GET requests return a noSuchErro and GETNEXT does not return the value.
- If hostd opens UDP/161 first, then third-party management objects and net-snmp is not available.
- If neither of the agents can open UDP/161, a timeout results.
Workaround: Perform the following tasks in sequence.
1. Stop the service console SNMP demon (snmpd) by using this command: service snmpd stop
2. Restart the VMware SNMP demon (hostd) by using this command: service mgmt-vmware restart

The health status of the ESX/ESXi host server components does not appear on the Hardware Status tab
If you change the HTTPS port number in the SFCB configuration file (sfcb.cfg) to a port other than the default and restart the SFCB (CIM) server, the health status of the ESX/ESXi host server components does not appear on the Hardware Status tab. This behavior is also seen if you log directly in to an ESX/ESXi host and click the Configuration tab to view the health status. Status information for the server components does not appear. This problem occurs because vCenter Server and the SFCB server are communicating on different ports.
Workaround: Make sure that the SFCB server communicates only through the default port.

SNMP PowerOn traps generated during vmware_hostd restart
When you restart vmware_hostd, only the Warm Start trap message should be generated by default. However, for all virtual machines running on your host, the PowerOn trap messages are also generated.
Workaround: You can ignore the PowerOn trap messages.

ESX/ESXi might fail to discover second port on certain IBM servers with dual-port FC HBAs
When you use IBM x3650 servers with dual-port FC HBAs, ESX/ESXi might fail to discover the second port. This problem can possibly happen on other IBM servers with the same version of BIOS.
Workaround: Depending on the type of adapter your server has, do one of the following:
- For QLogic HBAs, upgrade the IBM BIOS to the latest BIOS version (version 1.2).
- For Emulex HBAs the following solutions exist:

Storage

sg_inq command takes a long time to run on ESX 4.0 and later (KB 1029157) *
Copying large files from the ESX service console to a CIFS-mounted Windows disk might cause file corruption
Copying large files from the ESX service console to a Windows disk mounted using CIFS might cause file corruption.
Workaround: When mounting Windows disks in the service console using CIFS, use the forcedirection option.

During ESX installation, the entire physical disk selected for a datastore is automatically formatted with VMFS
You cannot adjust the size of the VMFS datastore even if you choose advanced partitioning during installation. By default, the installer deploys VMFS on the entire physical disk you select for the datastore.
Workaround: Use scripted installation to assign the required size to your VMFS datastore.

Entering additional static discovery targets for hardware iSCSI might fail
When you configure your hardware iSCSI adapter, an attempt to enter additional static discovery targets might fail. This occurs when a new target has the same iSCSI name as the existing one, even though their IP addresses are different.
Workaround: When configuring hardware iSCSI, use static discovery targets with different iSCSI names.

The path status for the CLARiiON iSCSI storage system changes from dead to active and from active to dead when the system is accessed through the ESX/ESXi software iSCSI initiator
When you use the software iSCSI initiator to access a CLARiiON iSCSI storage system, the path status frequently changes from dead to active and from active to dead. This occurs because CLARiiON does not support the advanced Delayed Ack parameter enabled on your ESX/ESXi host by default.
Workaround: Disable the Delayed Ack parameter on your ESX/ESXi host by performing the following steps:
1. Log in to the vSphere Client, and select a host from the inventory panel.
2. Click Configuration tab, and click Storage Adapters.
3. Select the software iSCSI initiator to configure and click Properties.
4. On the General tab, click Advanced.
5. Deselect Delayed Ack.

When you use the PSP_RR path selection policy with Failover Clustering, shared disks experience problems and the cluster may not operate
Failover Clustering conducts SCSI-3 reservations on shared disks. SCSI-3 registration sent down one path allows the cluster to do SCSI-3 reservations only on that path. When PSP_RR later switches to another path, Failover Clustering may be unable to do a reservation or use other SCSI-3 commands that depend on the reservation.
Workaround: Do not switch devices used for shared disks to PSP_RR. Instead, use the PSP_MRU or PSP_FIXED policies depending on the normal default for the array.

Adding a QLogic iSCSI adapter to an ESX/ESXi system fails if an existing target with the same name but a different IP address exists
Adding a static target for QLogic hardware iSCSI adapter fails if there is existing target with same iSCSI name, even if the IP address is different.
You can add a QLogic iSCSI adapter to an ESX/ESXi system only with a unique iSCSI name for a target, not the combination of IP and iSCSI name. In addition, the driver and firmware do not support multiple sessions to the same storage end point.

Workaround: None. Do not use the same iSCSI name when you add targets.

An error message appears after you enter the fdisk service console command with the absolute path of the disk
If you run the fdisk service console command and provide the absolute path for the disk (for example, fdisk -l /vmfs/devices/disks/naa.600a0b80002a071c0000834248ca0b4f), the following error message appears:

last_lba(): I don't know how to handle files with mode 8180
Workaround: You can ignore this error message or run the following command:

fdisk -l /dev/sdh

Booting from an iSCSI LUN might be too slow or fail
If any iSCSI configuration data is present before you start configuring an iSCSI boot device through the QLogic BIOS, you can create duplicate iSCSI sessions for the same target. When this occurs, I/O operations might be very slow and might fail.
Workaround: Perform the following steps:
1. In the BIOS, select the Clear Persistent Targets option to remove any existing iSCSI configuration data.
2. Add iSCSI boot configuration data.

The ESX service console does not recognize runtime changes made to the LUN size
If any changes are made to the size of a LUN available to your ESX host, the VMkernel detects the new size such that VMFS and virtual machines can use this new size. However, the service console still displays the old size until you reboot the host. This occurs because the service console obtains device capacity only on initial device probe.
Workaround: Reboot the ESX host. If you do not want to reboot, perform the following steps:
1. Make sure the host does not use the LUN.
2. Mask the LUN from the host.
3. From the vSphere Client, rescan the storage adapter that the host uses to access the LUN.
4. Unmask the LUN to make it accessible to the host.
5. Rescan the storage adapter.
The service console now displays the correct size of the LUN.

Changing the Maximum Outstanding R2T iSCSI parameter on your ESX/ESXi host to a value greater than one, might result in the EMC CX3 Series storage system not working properly
If you change the default value of the Maximum Outstanding R2T iSCSI parameter on your ESX/ESXi host to a value greater than one, the EMC CX3 Series storage system might not work properly.
Workaround: Do not change the default value of one for the Maximum Outstanding R2T parameter.

ESX might occasionally fail to boot from an iSCSI Clariion storage system
If you boot from iSCSI, your ESX host might not start when the Clariion storage system is used. This occurs because the QLogic adapter is attempting to boot from the standby SP on the Clariion storage and is not properly discovering the active SP.
Workaround: Make sure the primary and alternate boot LUNs in the QLogic BIOS are set to different SPs on the Clariion storage. Change the order of the boot LUNs if this problem persists.

Cannot perform port binding in conjunction with IPv6 ports
Port binding is a mechanism of identifying certain VMkernel ports for use by the iSCSI storage stack. Port binding is necessary to enable storage multipathing policies, such as the VMware round-robin load-balancing, MRU, or fixed-path, to apply to iSCSI NIC ports and paths. Port binding does not work in combination with IPv6. When users configure port binding, they expect to see additional paths for each bound VMkernel NIC. However, when they configure the array under a IPv6 global scope address the additional paths are not established. Users only see paths established on the IPv6 routable VMkernel NIC. For instance, if users have two target portals and two VMkernel NICs, they see four paths when using IPv4 but see only two paths when using IPv6. Because there are no paths for failover, path policy setup does not make sense.
Workaround: Use IPv4 and port binding, or configure the storage array and the ESX/ESXi host with LOCAL SCOPE IPv6 addresses on the same subnet (switch segment). You cannot currently use global scope IPv6 with port binding.

The ESX/ESXi host does not register a path added from Storage Manager Application
When you add a new port on a storage system using Storage Manager Application, your ESX/ESXi host does not display a new path to the storage system.
Workaround: Perform the following steps:
1. Make sure the port is accessible by the ESX/ESXi host.
2. Remove the physical connection for the newly added port.
3. Wait for the Device Delay Missing timer to expire.
4. Reconnect the physical connection.

Path for a device cannot be unclaimed after you disable autoclaiming
You cannot unclaim a path for a device after you set the autoclaiming option to Off/Disabled.
Workaround: The autoclaiming option is not supported in ESX/ESXi 4.0.

On rare occasions, after repeated SAN path failovers, operations that involve VMFS changes might fail for all ESX/ESXi hosts accessing a particular LUN
On rare occasions, after repeated path failovers to a particular SAN LUN, attempts to perform such operations as VMFS datastore creation, vMotion, and so on might fail on all ESX/ESXi hosts accessing this LUN. The following warnings appear in the log files of all hosts:
- I/O failed due to too many reservation conflicts.
- Reservation error: SCSI reservation conflict
If you see the reservation conflict messages on all hosts accessing the LUN, this indicates that the problem is caused by the SCSI reservations for the LUN that are not completely cleaned up.

Workaround: Run the following LUN reset command from any system in the cluster to remove the SCSI reservation:

vmkfstools -L lunreset /vmfs/devices/disks/

vCenter Server fails to open RDM after the RDMs LUN number changes
VMware does not support LUN number (position) changes within the target. When the LUN number changes vCenter Server fails to open the RDM that is built on that LUN. A raw device mapping file (RDM) resides on the VMFS datastore and points to a LUN. The LUN number shows the position of the LUN within the target. When this number (or position) changes, the vml identifier (vml_ID) for the RDM file also changes. For example, you cant disconnect VMFS datastores and reconnect them in a different order. This changes the identification of the LUN so that it is no longer accessible and vCenter Server prevents the virtual machine from powering on. vSphere Client uses the vml_ID for backward compatibility.
Workaround: Remove the RDM and re-create it. This generates a new vml_ID that the LUN can recognize.

vSphere Client displays drive fault alerts when the drive is not present on ESX and ESXi hosts with multi-node IBM systems
On some multi-node IBM systems, the BMC firmware reports a drive fault for drive slots when no drive is present. The vSphere Client reports the Drive Fault sensor as being in an Alert state. The same faults are shown in the IBM iLOM interface.
Workaround: None. A defect report is filed with IBM to address this issue.

NAS datastores report incorrect available space
When you view the available space for an ESX/ESXi host by using the df (ESXi) or vdf (ESX) command in the host service console, the space reported for ESX/ESXi NAS datastores is free space, not available space. The space reported for NFS volumes in the Free column when you select Storage > Datastores on the vSphere Client Configuration tab, also reports free space, and not the available space. In both cases, free space can be different from available space.
ESX file systems do not distinguish between free blocks and available blocks, but always report free blocks for both block types (specifically, f_bfree and f_bavail fields of struct statfs). For NFS volumes, free blocks and available might can be different.

Workaround: You can check NFS servers to get correct information regarding available space. No workarounds are available for ESX/ESXi.

Harmless warning messages concerning region conflicts are logged in the VMkernel logs for some IBM servers
When the SATA/IDE controller works in legacy PCI mode in the PCI config space, an error message similar to the following might appear in the VMkernel logs:

WARNING: vmklinux26: __request_region: This message has repeated 1 times: Region conflict @ 0x0 => 0x3

Workaround: Such error messages are harmless and can be safely ignored.

Granting permissions to modify a datastore allows users to modify system related files
Granting all datastore modification privileges to users enables them to change the system files on the local ESX datastore, including the service console VMDK file (esxconsole.vmdk). This file is located in a datastore in the /esxconsole- folder. If a user renames the esxconsole folder or the VMDK file, the ESX host cannot reboot.
Workaround: Allow only administrators to modify datastores. Make certain that users who have permission to modify datastores are aware of the problems that occur when the esxconsole folder or the esxconsole.VMDK file is renamed.

Using Storage vMotion to relocate a virtual machine back to its source volume might result in an insufficient disk space error
When you use Storage vMotion to move a virtual machine to another datastore and then back to its source volume, the vSphere Client does not immediately refresh the size of the source datastore, resulting in an error.
Workaround: Refresh the datastore in the vSphere Client. If the reported size of the datastore does not change after one attempt, wait for 30 minutes and refresh again.

vmfs-undelete utility is not available for ESX/ESXi 4.0
ESX/ESXi 3.5 Update 3 included a utility called vmfs-undelete, which could be used to recover deleted .vmdk files if they were not overwritten at the block level. This utility is not available with ESX/ESXi 4.0.
Workaround: None. Deleted .vmdk files cannot be recovered.

When the storage processor of the HP MSA2012fc storage array is reset, critical alerts are erroneously issued *
Resetting the storage processor of the HP MSA2012fc storage array causes the ESX/ESXi native multipath driver (NMP) module to send alerts or critical entries to vmkernel logs. These alert messages indicate that the physical media has changed for the device. However, these messages do not apply to all LUN types. They are only critical for data LUNs but do not apply to management LUNs.

Workaround: No workaround. In this scenario, you can safely ignore alerts logged in reference to management LUNs.

A virtual machine can go into an endless loop of resetting SCSI LUNs, which prevents the virtual machine from being shut down
When SCSI drivers (either BusLogic or LSI Logic) of a virtual machine resets its LUNs for any reason, the reset can go into endless loop.
Attempts to kill the virtual machine are not successful.

The guest operating system reports I/O errors related to LSI controllers
Online controller firmware upgrades on an array with an LSI controller might cause I/O failures on virtual machines accessing the array. Many arrays use an LSI controller. For example, the following is a list of a few of the common arrays using LSI controllers:
- IBM DS48xx series
- IBM DS 3xxx series
- Dell MD3xxx series
- Sun STK Flexline series
Workaround: Before upgrading the firmware on a storage controller, manually trespass all the LUNs to the other storage controller and ensure that the ESX/ESXi host is not sending I/O to the storage controller.

Service console commands might provide misleading information about Cisco UCS Qlogic FCoE controllers
On Cisco Unified Computing System (UCS) systems with a Qlogic FCoE controller, service console commands esxcfg-scsidevs -a and lspci might not identify the controller as a Qlogic FCoE controller, but instead specify the controller as a Fibre Channel controller.

For example, the output of the following service console commands does not identify the Cisco UCS Qlogic FCoE controllers specifically as FCoE controllers.
- The lspci command for Cisco UCS Qlogic FCoE Controllers:
  04:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03) 04:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
- The esxcfg-scsidevs -a command for Cisco UCS Qlogic FCoE Controllers:
  vmhba1 qla2xxx link-up fc.20010025b500000a:20000025b500001a (0:4:0.0) QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA vmhba2 qla2xxx link-up fc.20010025b500000a:20000025b500000a (0:4:0.1) QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA

Supported Hardware

VMware ESX might fail to boot on Dell 2900 servers
If your Dell 2900 server has a version of BIOS earlier than 2.1.1, ESX VMkernel might stop responding while booting. This is due to a bug in the Dell BIOS, which is fixed in BIOS version 2.1.1.
Workaround: Upgrade BIOS to the version 2.1.1 or later.

No CIM indication alerts are received when the power supply cable and power supply unit are reinserted into HP servers
No new SEL(IML) entries are created for power supply cable and power supply unit reinsertion into HP servers when recovering a failed power supply. As a result, no CIM indication alerts are generated for these events.
Workaround: None

Core Dump fails with a timeout message
Configuring a device connected to a Perc 4/DC controller as a core dump device on which to store crash dumps in the event of a system crash can lead to timeouts and unsaved core dumps. This timeout behavior has been observed with different firmware versions on this controller (for example, 352B and 352D) and only for system crashes. No issues have been observed with I/O to the same device when the system is running.
Workaround: Do not configure a device connected to the Perc 4/DC controller as a core dump device for ESX/ESXi 4.0 systems.

Slow performance during virtual machine power-On or disk I/O on ESX/ESXi on the HP G6 Platform with P410i or P410 Smart Array Controller
Some of these hosts might show slow performance during virtual machine power on or while generating disk I/O. The major symptom is degraded I/O performance, causing large numbers of error messages similar to the following to be logged to /var/log/messages.
Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL! Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL! Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x Mar 25 17:39:26 0 0x0 0x0. Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)WARNING: NMP: nmp_DeviceRetryCommand: Device "naa.600508b1001030304643453441300100": awaiting fast path state update for failoverwith I/O blocked. No prior reservation exists on the device. Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060700) to NMP device "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x Mar 25 17:39:26 0 0x0 0x0.

Workaround: Install the HP 256MB P-series Cache Upgrade module.

Some Dell BIOSes may have duplicate interrupt routing entries in the ACPI table (KB 1013804)

On certain versions of vSphere Client, the battery status might be incorrectly listed as an alert
In vSphere Client from the Hardware Status tab, when the battery is in its learn cycle, the battery status provides an alert message indicating that the health state of the battery is not good. However, the battery level is actually fine.

Workaround: None.

A "Detected Tx Hang" message appears in the VMkernel log
Under a heavy load, due to hardware errata, some variants of e1000 NICs might lock up. ESX/ESXi detects the issue and automatically resets the card. This issue is related to Tx packets, TCP workloads, and TCP Segmentation Offloading (TSO).

Workaround: You can disable TSO by setting the /adv/Net/UseHwTSO option to 0 in the esx.conf file.

Problems with TEAC DV-28E-V DVD drive
If an ESX/ESXi host is physically connected to a TEAC DV-28E-V DVD drive with old firmware (for example, C.AB), the virtual machine, host daemon, or ESX/ESXi host might become non responsive. The problem does not occur each time, and it is more likely to occur with Windows virtual machines.
Workaround: Upgrade the DVD drive firmware to the latest version or replace the DVD drive with a different model.

Upgrade and Installation

Upgrade from ESX 4.0 to ESX 4.0.x or ESX 4.x by using the esxupdate command results in an error message (KB 1038732) *
The vCenter Server system's Database Upgrade wizard might overestimate the disk space requirement during an upgrade from VirtualCenter 2.0.x to vCenter Server 4.0
During the upgrade of VirtualCenter 2.0.x to vCenter Server 4.0, the Database Upgrade wizard can show an incorrect value in the database disk space estimation. The estimation shown is typically higher than the actual space required.
Workaround: None

vSphere Client installation might fail with Error 1603 if you do not have an active Internet connection
You can install the vSphere Client in two ways: from the vCenter Server media or by clicking a link on the ESX, ESXi, or vCenter Server Welcome screen. The installer on the vCenter Server media (.iso file or .zip file) is self-contained, including a full .NET installer in addition to the vSphere Client installer. The installer called through the Welcome screen includes a vSphere Client installer that makes a call to the Web to get .NET installer components.
If you do not have an Internet connection, the second vSphere Client installation method will fail with Error 1603 unless you already have .NET 3.0 SP1 installed on your system.

Workaround: Establish an Internet connection before attempting the download, install the vSphere Client from the vCenter Server media, or install .NET 3.0 SP1 before clicking the link on the Welcome screen.

Opening performance charts after an upgrade results in an error message
After you perform an upgrade using the Microsoft SQL Express edition database, the vSphere Client displays the error message Perf Charts service experienced an internal error when you open performance charts. This happens because the installer does not restart the database service after making changes in the database settings.
Workaround: Perform the following steps:
1. Stop the VMware VirtualCenter Server service in Windows.
2. Restart the database service.
3. Start the VMware VirtualCenter Server service.
4. Open a new vSphere Client instance and log into vCenter Server.

Some kickstart commands for scripted installations of ESX 4.0 have been deprecated or are not supported in this release
If you have an install script that does not work for ESX 4.0, this might be because the script contains deprecated or unsupported commands. The following kickstart commands are deprecated:
autostep clearpart --linux clearpart --exceptvmfs cmdline device deviceprobefirewall --enabled (replaced by esxcfg-firewall --blockIncoming and esxcfg-firewall --blockOutgoing)
firewall --disabled (replaced by esxcfg-firewall --allowIncoming and esxcfg-firewall --allowOutgoing)
firstboot harddrive ignoredisk interactive lang(The default setting is used.)langsupport(The default setting is used.)lilo lilocheck logvol mouse part --onvmdk raid skipx text vmaccepteula(now called accepteula)vnc volgroup xconfig xdisplay %packages(The new method for customizing packages is to use packages.xml)%vmlicense_text

The following Red Hat Enterprise Linux 3 commands are not supported:

autostep cmdline device deviceprobe firewall --blockIncoming firewall --blockOutgoing firstboot harddrive ignoredisk interactive lang langsupport lilo lilocheck logvol mouse raid skipx text vnc volgroup xconfig xdisplayWorkaround: Use only the kickstart commands supported by VMware. For a detailed list of supported commands, see the ESX and vCenter Server Installation Guide.

If you choose a shared datastore for the service console, the software installer or upgrade tool does not issue a warning
For ESX 4.0, the service console must be installed on a VMFS datastore that is resident on a host's local disk or on a SAN disk that is masked and zoned to that particular host only. This release does not support installing the service console on a datastore that is shared between hosts. When you install ESX 4.0 or upgrade to ESX 4.0, you must select a VMFS datastore location for the service console (esxconsole.vmdk). If you select a datastore that is shared between hosts, the software installer or upgrade tool does not issue a warning.
Workaround: Do not install the service console on a VMFS datastore shared between hosts.

If SQL Native Client is already installed, you cannot install vCenter with the bundled SQL Server 2005 Express database
When you are installing vCenter with the bundled SQL Server 2005 Express database, if SQL Native Client is already installed, the installation fails with the following error message:
An Installation package for the product Microsoft SQL Native Client cannot be found. Try the installation using a valid copy of the installation package sqlcli.msi.

Workaround: Uninstall SQL Native Client if it is not used by another application. Then, install vCenter with the bundled SQL Server 2005 Express database.

The vmxnet driver is not installed automatically when you install or upgrade VMware Tools
When you install or upgrade VMware Tools on a virtual machine running the Windows NT guest operating system, the vmxnet driver is not installed automatically.
Workaround: Install the vmxnet driver manually. To do this, perform the following steps:
1. Log in to the virtual machine and right-click Network Neighborhood.
2. Click Properties and select the Adapters tab.
3. Click Have Disk and enter the path to the driver:
  C:\Program Files\VMware\VMware Tools\Drivers\vmxnet\
4. Reboot the virtual machine.

The graphical installer does not load when booting ESX on a Dell Precision T3400 workstation
When you try to use the graphical installer to install ESX on a Dell Precision T3400 workstation, the installation fails.
Workaround: Use the text installer instead.

Cannot reinstall or uninstall product after terminating the uninstallation of vSphere Client 4.0
If vSphere Client installation is interrupted, a subsequent installation or uninstallation of the vSphere Client 4.0 results in the following error message:
Error applying transforms. Verify that the specified transform paths are valid.

Workaround: Use the Windows Installer Cleanup to uninstall vSphere Client 4.0.

The VMware Web Access kickstart script generator is not supported
For ESX scripted installation, the VMware Web Access script generator is not available in vSphere 4.0.
Workaround: You can use the kickstart script that is auto-generated after an interactive installation. After the first interactive installation of ESX, the installer creates a /root/ks.cfg script in the ESX file system. This script reflects the choices you made in the interactive installation. For a complete list of supported commands and a sample script, see the ESX and vCenter Server Installation Guide.

Uninstalling the vSphere Client leaves behind empty directories
When you uninstall the vSphere Client, empty directories remain.
Workaround: Navigate to the installation directory and delete the Virtual Infrastructure Client directory.

A minimum of 650MB of free space on the boot drive is required to install vCenter Server
Although vCenter Server itself does not need to be installed on the boot drive, some required components must be installed on the boot drive. 650MB of free space is required at installation time to accommodate these required components as well as temporary files used during the installation.
Workaround: Ensure that you have at least 650MB of free space on the boot drive before installing vCenter Server.

vSphere Client 4.0 download times out with an error message when you connect VI Client 2.0.x on a Windows 2003 machine to vCenter Server or an ESX/ESXi host
If you connect a VI Client 2.0.x instance to vCenter Server 4.0 or an ESX/ESXi 4.0 host, vSphere Client 4.0 is automatically downloaded onto the Windows machine where the VI Client resides. This operation relies on Internet Explorer to perform this download. By default, Internet Explorer on Windows 2003 systems blocks the download if the VI Client instance is VI Client 2.0.x.
Workaround: In Internet Explorer, select Tools > Internet Options > Advanced and uncheck the option Do not save encrypted pages to disk. Alternatively, download and install vSphere Client 4.0 manually from vCenter Server 4.0 or the ESX/ESXi 4.0 host.

ESX/ESXi installation might fail on IBM x336 machines due to BIOS incompatibility
On some IBM x336 machines, the ESX/ESXi installation process might stop. This is caused by a bug in the machine's BIOS.
Workaround: Update the machine's BIOS to version 1.15 prior to installing ESX or ESXi Installable.

When you use vSphere Host Update Utility to perform an ESX host upgrade, the upgrade might fail
When you use vSphere Host Update Utility to perform an ESX upgrade, the upgrade might fail with the following error:
An error occurred during upgrade. Connection with upgrade agent has been lost.

This happens when the upgrade is 26 percent complete. In the service console, the process halts on Stopping VMware ESX server Management services.

Workaround: Reboot the ESX host manually by pressing the reset button. The ESX upgrade continues and completes successfully, but vSphere Host Update Utility does not display the progress. To view the current host status from vSphere Host Update Utility, click Retry.

When you install ESX using the local DVD method and you use a particular DVD model, the ESX installation fails
Local installation of ESX fails when you use SONY AMAX 270 DVD RW AW-Q170A, Rev: 1.70. The DVD is not detected.
Workaround: Upgrade the firmware to SONY DVD RW AW-Q170A, Rev: 1.74, and then retry the installation.

vCenter Server database upgrade fails for Oracle 10gR2 database with certain user privileges
If you upgrade VirtualCenter Server 2.x to vCenter Server version 4.0 and you have connect, create view, create any sequence, create any table, and execute on dbms_lock privileges on the database (Oracle 10gR2), the database upgrade fails. The VCDatabaseUpgrade.log file shows following error:
Error: Failed to execute SQL procedure. Got exception: ERROR [HY000] [Oracle][ODBC][Ora]ORA-01536: space quota exceeded for tablespace 'USERS'

Workaround: As database administrator, enlarge the user tablespace or grant the unlimited tablespace privilege to the user who performs the upgrade.

vCenter Server installation fails on Windows Server 2008 when using a nonsystem user account
When you specify a non-system user during installation, vCenter Server installation fails with the following error message:
Failure to create vCenter repository

Workaround: On the system where vCenter Server is being installed, turn off the User Account Control option under Control Panel > User Accounts before you install vCenter Server. Specify the non-system user during vCenter Server installation.

Incompatible legacy plug-ins appear as enabled in the vSphere Plug-in Manager after upgrading to vCenter Server 4.0
If you have VirtualCenter 2.5 installed with VMware Update Manager 1.0 or VMware Converter Enterprise for VirtualCenter 2.5, and you upgrade to vCenter Server 4.0, the legacy plug-ins appear as installed and enabled in the vSphere Client Plug-in Manager. However, earlier versions of the plug-in modules are not compatible with vCenter Server 4.0. In such cases, the plug-ins might be available, but are not functional.
Workaround: Upgrade VMware Update Manager to VMware vCenter Update Manager 4.0 and VMware Converter Enterprise to VMware vCenter Converter (for vCenter Server 4.0), and then install and enable the plug-ins.

Cannot log in to VirtualCenter Server 2.5 after installing VI Client 2.0.x, 2.5, and vSphere Client 4.0 and then uninstalling VI Client 2.0.x on a Windows Vista system
After you uninstall the VI Client 2.0.x on a Windows Vista machine where the VI Client 2.0.x, 2.5, and the vSphere Client 4.0 coexist, you cannot log in to vCenter Server 2.5. Login fails with the following message:
Class not registered(Exception from HRESULT:0x80040154(REGDB_E_CLASSNOTREG))

Workaround: Disable the User Account Control setting on the system where VI Client 2.0.x, 2.5, and vSphere Client 4.0 coexist,or uninstall and reinstall VI Client 2.5.

The ESX/ESXi installer lists local SAS storage devices in the Remote Storage section
When displaying storage locations for ESX or ESXi Installable to be installed on, the installer lists a local SAS storage device in the Remote Storage section. This happens because ESX/ESXi cannot determine whether the SAS storage device is local or remote and always treats it as remote.
Workaround: None

When you install ESX on some Dell servers using the DRAC5 virtual CD-ROM method, the ESX installation fails
The virtual media becomes disconnected when you try to install ESX on some Dell PowerEdge servers by using the DRAC5 virtual CD-ROM method.
Workaround: Instead of using virtual media, install ESX from the local CD-ROM, or update the firmware version to Version 1.33 (08.03.10).

If vSphere Host Update Utility loses its network connection to the ESX host, the host upgrade might not work
If you use vSphere Host Update Utility to perform an ESX/ESXi host upgrade and the utility loses its network connection to the host, the host might not be completely upgraded. When this happens, the utility might stop, or you might see the following error message:
Failed to run compatibility check on the host.

Workaround: Close the utility, fix the network connection, restart the utility, and rerun the upgrade.

vCenter Server installer reports incorrect warning message during an installation or upgrade
During installation or upgrade, the vCenter Server installer reports a warning message to enable TCP/IP and named pipes for remote connections. This message is reported if you use a local SQL Server database and enter the server name something other than (local) and "." when you create DSN.
Workaround: Ignore the warning and click OK to continue the installation or upgrade.

vSphere Client fails with Microsoft Visual C++ Runtime Library error
In environments that include vSphere 4.0 components, VI Client version 2.5, and VMware vCenter Converter, the vSphere Client might fail with a Microsoft Visual C++ Runtime Library runtime exception.
Workaround: Delete libeay32.dll and ssleay32.dll located at the following path:
C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher
Alternatively, uninstall VI Client version 2.5.

vCenter Server installation on Windows Server 2008 with a remote SQL Server database fails in some circumstances
If you install vCenter Server on Windows 2008, using a remote SQL Server database with Windows authentication for SQL Server, and a domain user for the DSN that is different from the vCenter Server system login, the installation does not proceed and the installer displays the following error message:
25003.Setup failed to create the vCenter repository

Workaround: In these circumstances, use the same login credentials for vCenter Server and for the SQL Server DSN.

Upgrading the hardware version of Windows virtual machines might require driver updates
Upgrading the hardware version of a Windows virtual machine to hardware version 7 on an ESX 4.0 host will cause the Flexible network adapter to incorrectly use the AMD PCNet family PCI Ethernet adapter (pcnetpci5.sys) driver and have 10Mbps speed. The correct driver is the VMware Accelerated AMD PCNet Adapter (vmxnet.sys) driver.
Workaround: Manually update the driver for the Flexible NIC to the VMware Accelerated AMD PCnet Adapter (vmxnet.sys) driver by pointing to C:\Program Files\VMware\VMware Tools\Drivers\vmxnet\vmware-nic.inf from the virtual machine Windows guest.

An ESX host's resource pool settings might not be preserved after upgrading from ESX Server 3.0.x or ESX Server 3.5.x to ESX 4.0
If the ESX host is configured to reserve all, most, or almost all available host capacity in the resource pool CPU reservation and memory reservation settings, the settings might not be preserved after upgrading from ESX Server 3.0.x or ESX 3.5.x to ESX 4.0. After an upgrade, the reservation settings drop to zero. This issue applies to standalone hosts only. DRS clusters are not affected.
Workaround: Do not reserve all or close to all available host capacity in the resource pool CPU reservation and memory reservation settings. If you do, note the information related to the host-level resource pool settings before the upgrade and then change the information manually after the upgrade.

The vSphere Host Update Utility reports an error after attempting to upgrade an ESX host after the initial upgrade fails
If you try to upgrade a host by using the Retry option after the initial upgrade fails, the vSphere Host Update Utility might report the error:
Upgrade Agent Error:1

Workaround: Close and restart the vSphere Host Update Utility. Then run the host upgrade.

The Next run time value for some scheduled tasks is not preserved after you upgrade from VirtualCenter 2.0.2.x to vCenter Server 4.0
If you upgrade from VirtualCenter 2.0.2.x to vCenter Server 4.0, the Next run time value for some scheduled tasks might not be preserved and the tasks might run unexpectedly. For example, if a task is scheduled to run at 10:00 am every day, it might run at 11:30 am after the upgrade.
This problem occurs because of differences in the way that VirtualCenter 2.0.2.x and vCenter Server 4.0 calculate the next run time. You see this behavior only when the following conditions exist:
- You have scheduled tasks, for which you edited the run time after the tasks were initially scheduled so that they now have a different Next run time.
- The newly scheduled Next run time has not yet occurred.
Workaround: Perform the following steps:
1. Wait for the tasks to run at their scheduled Next run time before upgrading.
2. After you upgrade from vCenter 2.0.x to vCenter Server 4.0, edit and save the scheduled task. This process recalculates the Next run time of the task to its correct value.

ESX Server 2.5 virtual machines with non-persistent disks upgraded to ESX 4.0 might enter a suspended state
When you upgrade the virtual hardware of an ESX Server 2.5 virtual machine with non-persistent disks (identifiable by config version = 6, hardware version = 3) in ESX 4.0, the virtual machine will be incorrectly set to autorevert. If you take snapshots on this virtual machine (identifiable by config version = 8, hardware version = 7) in ESX 4.0, the virtual machine might enter a suspended state while reconfiguring its virtual hardware devices in the powered-off state.
Workaround: Remove the entry snapshot.action = "autoRevert" from the configuration file manually after you upgrade the virtual machine.

Installation or upgrade of vCenter Server 4.0 might fail with disk space error
During installation of vCenter Server 4.0, when you provide the amount of free space estimated by the installer, the installation might fail and issue a Not enough disk space error message. As a result, you might have to rerun the installation.
Workaround: Provide at least 1GB of free space in addition to the amount recommended by the installer.

Virtual machine hardware upgrades from version 4 to version 7 cause Solaris guests lose their network settings
Virtual machine hardware upgrades from version 4 to version 7 changes the PCI bus location of virtual network adapters in guests. Solaris does not detect the adapters and changes the numbering of its network interfaces (for example, e1000g0 becomes e1000g1). This numbering change occurs because Solaris IP settings are associated with interface names, so it appears that the network settings have been lost and the guest is likely not to have proper connectivity.
Workaround: Determine the new interface names after the virtual machine hardware upgrade by using the prtconf -D command, and then rename all the old configuration files to their new names. For example, e1000g0 might become e1000g1, so every /etc/*e1000g0 file should be renamed to its /etc/*e1000g1 equivalent.

The vCenter Server installer cannot detect service ports if the services are not running
When you install vCenter Server and accept the default ports, if those ports are being used by services that are not running, the installer cannot validate the ports. The installation fails, and an error message might appear, depending on which port is in use.
This problem does not affect IIS services. IIS services are correctly validated, regardless of whether the services are running.

Workaround: Verify which ports are being used for services that are not running before beginning the installation and avoid using those ports.

vCenter Server service might not start if vCenter Server is installed as a local system account on a local Microsoft SQL Server database with Integrated Windows NT Authentication
If you install an instance of vCenter Server as a local system account on a local SQL Server database with Integrated Windows NT Authentication and then add an Integrated Windows NT Authentication user to the local database server with the same default database as vCenter Server, vCenter Server might not start.
Workaround: Remove the Integrated Windows NT Authentication user from the local SQL database server. Alternatively, change the default database for the local system user account to the vCenter Server database for the SQL Server user account setup.

Some commands might not work in the %pre and %post sections of kickstart file
Some commands, such as mount, supported for installation of previous versions of ESX with kickstart files might not work with the %pre and %post sections in the kickstart file for installations of ESX 4.0.
Workaround: Update the %pre and %post sections of kickstart files used in installation scripts.

Installing a patch on ESX 4.0 with EMC Power Path installed prevents the rpowermt utility from discovering LUNs (KB 1016421)

Upgrading to Update 1 using vihostupdate fails with the Cisco Nexus 1000V installed (KB 1015879)

Applicable bulletins are not listed when scanning the host machine using vihostupdate command
Scanning the host machine by using vihostupdate --scan command for the applicable bulletins, after downloading the bundle ZIP file for ESX 4.0 Update 3, does not list the all the bulletins contained in the bundle.

Workaround: Use the esxupdate utility to list the available bulletins in the ESX 4.0 Update 3 bundle. For more information on the esxupdate utility, see the ESX 4 Patch Management Guide.

esxupdate downloads the latest version of a VIB if the dependent version is not available in the bulletin list *
When you install a patch on ESX by using the esxupdate command, the command downloads the latest version of a VIB instead of the specific version that your ESX installation uses. Such an update occurs when your installation requires a specific version of the VIB, and that version of VIB is not available in the bulletin list.

vCenter Server, vSphere Client, and vSphere Web Access

Alarms with health status trigger conditions are not migrated to vSphere 4.0
The vSphere 4.0 alarm triggers functionality has been enhanced to contain additional alarm triggers for host health status. In the process, the generic Host Health State trigger was removed. As a result, alarms that contained this trigger are no longer available in vSphere 4.0.
Workaround: Use the vSphere Client to recreate the alarms. You can use any of the following pre configured VMware alarms to monitor host health state:
- Host battery status
- Host hardware fan status
- Host hardware power status
- Host hardware temperature status
- Host hardware system board status
- Host hardware voltage
- Host memory status
- Host processor status
- Host storage status
If the pre configured alarms do not handle the health state you want to monitor, you can create a custom host alarm that uses the Hardware Health changed event trigger. You must manually define the conditions that trigger for this event alarm. In addition, you must manually set which action occurs when the alarm triggers.

Note: The pre configured alarms already have default trigger conditions defined for them. You only need to set which action occurs when the alarm triggers.

Web Access service does not start after finishing ESX installation
When you use Web Access to connect to an ESX host, the following message appears:
503 Service Unavailable

The reason is that after you finish installing ESX, the Web Access service does not start automatically.

Workaround: To start the Web Access service on the ESX host, run the following command: service vmware-webAccess start

Using the vSphere Client Delete All option to remove virtual machine snapshots might leave the snapshot disk files in the virtual machine folder
This behavior occurs only when you previously used the snapshot to create linked clones and then deleted them from the vCenter Server. If you now attempt to remove the snapshot using the Snapshot Managers Delete All option, the snapshot is deleted. However, the snapshot disk is not consolidated with the parent disk and is left undeleted in the virtual machine folder.
Workaround: Instead of using the "Delete All" option, use the "Delete" option to remove the snapshot.

Configuring NTP in the vSphere Client modifies the time zone in the host
Host time zone currently cannot be configured through the vSphere Client, but can be configured through the service console. Host NTP settings can be configured through the vSphere Client. If the host time zone is manually changed and NTP settings are subsequently configured through the vSphere Client, the host time zone is overwritten by the vSphere Client with an old value.
Workaround: After manually changing the host time zone, close and reconnect any connected clients. Clients will obtain the new time zone value.

If a system has virtual network adapter, Guided Consolidation might compute a larger number of NICs for that system than the number of physical NICs
The number of NICs for a system computed by Guided Consolidation can be larger than the number of physical NICs for the system if the system has virtual network adapters. In this case, you might get the following warning during the Plan Consolidation phase: "Host does not have the desired number of VM networks. A consolidation will result in the mapping of multiple networks of the physical computer to a single VM network." This happens for any machine with virtual NICs (for example, for any virtual machine and any (physical or virtual) machine running VMware Workstation or other hosted virtualization platform).
Workaround: No workaround needed. You can ignore the warning.

The Hardware Status tab does not display the ESX/ESXi host's hardware status information
The Hardware Status tab in the vSphere Client does not populate the hardware status of the selected ESX/ESXi host when the vCenter Server machine or ESX/ESXi host are running in pure IPv6 mode.
Workaround: Add and configure the IPv4 interface for both the vCenter Server machine and the ESX/ESXi host.

Guided Consolidation cannot import systems that are running vCenter Converter
Guided Consolidation import operations encounter a problem when the source system (the imported system) is running vCenter Converter. Guided Consolidation imports the system and attempts to uninstall vCenter Converter from the source system. The import operation succeeds but the following error is displayed when Guided Consolidation attempts to uninstall vCenter Converter:
VMware Converter Agent Install failed.

Workaround: Uninstall vCenter Converter from source systems before attempting to import them using Guided Consolidation.

Web shortcuts to ESX Server 3.5 virtual machines stop working when you upgrade to ESX 4.0
Web shortcuts created for ESX Server 3.5 virtual machines cannot be accessed by users when you upgrade to ESX 4.0. vSphere Web Access 4.0 does not support the URLs for ESX 3.5. User cannot access virtual machines using the URLs created for ESX Server 3.5.
Workaround: Use vSphere Web Access 4.0 to create Web shortcuts that are valid for ESX 4.0 and distribute them to your users. For more information about creating Web shortcuts, see the vSphere Web Access Administrator's Guide.

For VMDirectPath Gen I, sharing a dual-function QLogic 2532 adapter between a virtual machine and either another virtual machine or the VMkernel might result in data corruption
When you configure a dual-function QLogic 2532 adapter for VMDirectPath IO, and assign the first PCI function to a virtual machine and the second to either the VMkernel or another virtual machine, data corruption might occur. This happens because both ports use the same credentials to log in to the fabric and have the same storage visibility. VMware does not support this configuration for VMDirectPath IO.
Workaround: If you cannot avoid sharing the dual-function adapter between a virtual machine and the VMkernel, assign the first PCI function to the virtual machine and the second to the VMkernel. The PCI functions cannot be split between two virtual machines.

The vSphere Client does not update sensors that are associated with physical events
The vSphere Client does not always update sensor status. Some events can trigger an update, such as a bad power supply or the removal of a redundant disk. Other events, such as chassis intrusion and fan removal, might not trigger an update to the sensor status.
Workaround: None

vCenter Server allows addition of the same ESX/ESXi system twice with two different IPv6 addresses
If you add an ESX/ESXi system to the vCenter inventory, and if that system is already managed by vCenter under a different IP address, the vCenter Server does not detect the problem. The ESX/ESXi system appears in the inventory with a new IP address, with status disconnected. Connections to the ESX/ESXi system that use the old IP address remain active.
Workaround: Do not add the same ESX/ESXi system twice.

Restarting mgmt-vmware does not restart vmware-webAccess
When you restart the mgmt-vmware service, the vmware-webAccess service does not restart. Instead, the service stops after a while and you cannot use Web Access to connect to the ESX host.
Workaround: Start the vmware-webAccess service manually. Do this by running the following command in the ESX service console: service vmware-webAccess start

Adapter Type drop-down menu missing vmxnet3 option on virtual machine running SUSE Enterprise Linux
A virtual machine running SLES 10 or SLES 11 for which SLES is selected as the guest operating system type does not include vmxnet3 in the Adapter Type drop-down menu. The problem is most likely to occur in virtual machines that are migrated from ESX Server 3.x to ESX 4.x, but it might also occur in other circumstances.
Workaround: The vmxnet3 option becomes available if you change the guest operating system type from SLES to SLES10 or SLES11.
1. Power off the virtual machine.
2. Right-click the virtual machine and select Edit Settings.
3. In the Options tab, click General Options.
4. In the version field, select either SLES10 or SLES11.

Virtual machines disappear from the virtual switch diagram in the Networking View for host configuration
In the vSphere Client Networking tab for a host, virtual machines are represented in the virtual switch diagram. If you select another host and then return to the Networking tab of the first host, the virtual machines might disappear from the virtual switch diagram.
Workaround: Select a different view in the Configuration tab, such as Network Adapters, Storage, or Storage Adapters, and return to the Networking tab.

Using special characters in virtual machine names during virtual machine creation results in an error when connected to vCenter Server with vSphere Web Access
When connected to vCenter Server with vSphere Web Access, using special characters, such as :"|\'{}[]-*^&@#!`~, in the virtual machine name during virtual machine creation triggers the following error:
RuntimeFault: A general system error occurred.
Workaround: None

vSphere Web Access displays incorrect virtual machine CPU speed after the number of virtual processors is increased
In vSphere Web Access, the Performance section of the Summary tab for a selected virtual machine displays incorrect information about CPU speed after the number of CPUs for the virtual machine has been increased. For example, if the number of CPUs for a virtual machine are increased from 1 CPU with a clock speed of 1.559Mhz to 2 CPUs, vSphere Web Access should display the number of CPUs and their clock speed as 2 x 1.559Mhz. However, the clock speed is incorrectly displayed as 3.117 (1.559 multiplied by 2).
Workaround: None

If you change the HTTPS port number in the SFCB configuration file (sfcb.cfg) to a port other than the default and restart the SFCB (CIM) server, the health status of the ESX/ESXi host server components does not appear on the Hardware Status tab
This behavior is also seen if you log directly in to an ESX/ESXi host and click the Configuration tab to view the health status. Status information for the server components does not appear.
This problem occurs because vCenter Server and the SFCB server are communicating on different ports.

Workaround: Make sure that the SFCB server communicates only through the default port.

Starting or stopping the vctomcat Web service at the Windows command prompt might result in an error message
On Windows operating systems, if you use the net start and net stop commands to start and stop the vctomcat Web service, the following error message might appear:
The service is not responding to the control function. More help is available by typing NET HELPMSG 2186.

Workaround: You can ignore this error message. If you want to stop the error message from occurring, modify the registry to increase the default timeout value for the service control manager (SCM). For more information, see the following Microsoft KB article: http://support.microsoft.com/kb/922918.

Overview performance charts do not display after upgrade from vCenter Server 2.5 with SQL Express bundled database
If you upgrade from a vCenter Server 2.5 to vCenter Server 4.0 using an SQL Express bundled database, Overview performance charts won't display. When you open the Overview view of the Performance tab, the following error appears:
STATs Report service internal error

This error occurs because the vCenter Server upgrade tool cannot reconfigure the existing database. You must manually perform the configuration.

Workaround:
1. Choose Start > Program Files > SQL Server Configuration Manager.
2. In the SQL Server Configuration Manager, do the following:
  1. Select Protocols for SQLEXP_VIM.
  2. Select TCP/IP.
  3. In Enabled, select True and in Listen All, select Yes.
  4. Click OK.
3. In a command window, type Services.msc to open the Service Manager.
4. In the Services list, start the following services:
- SQL Server 2005 Services: SQL Server (SQLEXP_VIM)
- SQL Server 2005 Services: SQL Browser (If SQL Browser service is disabled mark it for automatic/manual start)
- VMware vCenter service
- VMware web service

Error message appears if you add a second virtual disk to a virtual machine
Suppose you create a virtual machine with default options by using Web Access connected to ESX/ESXi 4.0. If you then connect from vSphere Web Access to the vCenter Server that manages the ESX/ESXi host and add a second virtual disk to the same virtual machine with the option Create a New Virtual Disk, the error The specified file already exists on the server appears.
Workaround: Use the vSphere Client to connect to vCenter Server and add a second virtual disk to the virtual machine.

The vc-support command uses a 64-bit DSN application and cannot gather data from the vCenter Server database
When you use the VMware cscript vc-support.wsf command to retrieve data from the vCenter Server database, the default Microsoft cscript.exe application is used. This application is configured to use a 64-bit DSN rather than a 32-bit DSN, which is required by the vCenter Server database. As a result, errors occur and you cannot retrieve the data.
Workaround: At a system prompt, run the vc-support.wsf command with the 32-bit DSN cscript.exe application:

%windir%\SysWOW64\cscript.exe vc-support.wsf

The vSphere Client Roles menu does not display role assignments for all vCenter Server systems in a Linked Mode group
When you create a role on a remote vCenter Server system in a Linked Mode group, the changes you make are propagated to all other vCenter Server systems in the group. However, the role appears as assigned only on the systems that have permissions associated with the role. If you remove a role, the operation only checks the status of the role on the currently selected vCenter Server system. However, it removes the role from all vCenter Server systems in the Linked Mode group without issuing a warning that the role might be in use on the other servers.
Workaround: Before you delete a role from vCenter Server system, ensure that the role is not being used across other vCenter Server systems. To see if a role is in use, go to the Roles view and use the navigation bar to select each vCenter Server system in the group. The role's usage is displayed for the selected vCenter Server system.

See vSphere Basic System Administration to learn about best practices for users and groups as well as information on setting roles for Linked Mode vCenter Server groups.

Snapshot deletion and virtual machine hot clone operations might take a long time when the virtual machine runs a heavy workload
Deleting a snapshot or cloning a powered-on virtual machine might take a long time to complete when the virtual machine is running a heavy input/output workload. For example, when the virtual machine writes to its local disks, the input/output load is very heavy.
Workaround: Avoid these operations when the virtual machine is writing to its local disks or issuing any other heavy input/output workloads. This can help to reduce the completion time.

Joining a Linked mode group after installation is unsuccessful if UAC is enabled on Windows Server 2008
When User Account Control (UAC) is enabled on Windows Server 2008 32- or 64-bit operating systems and you try to join a machine to a Linked Mode group on a system that is already running vCenter Server, the link completes without any errors, but it is unsuccessful. Only one vCenter Server appears in the inventory list.
Workaround: Complete the following procedures.

After installation, perform the following steps to turn off UAC before joining a Linked Mode group:
1. Select Start>Setting>Control Panel>User Accounts to open the User Accounts dialog box.
2. Click Turn User Account control on or off.
3. Deselect User Account Control (UAC) to help protect your computer and click OK.
4. Reboot the machine when prompted.
Start the Linked Mode configuration process as follows:
1. Select Start > All Programs > VMware > vCenter Server Linked Mode Configuration.
2. Click Next.
3. Select Modify Linked-Mode configuration and click Next.
4. Click Join this vCenter Server instance to an existing Linked-Mode group or another instance and click Next.
5. Enter the server name and LDAP port information and click Next.
6. Click Continue to complete the installation.
7. Click Finish to end the linking process.
Log in to one of the vCenter Servers and verify that the servers are linked. After the vCenter Servers are linked, turn on UAC as follows:
1. Select Start > Setting > Control Panel > User Accounts to open the User Accounts dialog box.
2. Click Turn User Account control on or off.
3. Select User Account Control (UAC) to help protect your computer and click OK.
4. Reboot the machine when prompted.

Removing a virtual machine's virtual switch that is being used might result in an error message
If you try to remove a virtual switch that a powered-on virtual machine is using, an error message appears. The warning message should alert you that the virtual switch is in use and cannot be removed. Removing virtual switches in such cases might cause the virtual machine to become unusable.
Workaround: Do not remove a virtual switch that is in use.

You cannot re-display the toolbar in the Reports view of the Storage Views tab after you hide it
The Reports view of the Storage Views tab has a toolbar that contains an object filter menu and a search field. These controls enable you to filter the reports tables based on object type, storage attributes, and keywords. If you hide the toolbar by selecting Hide from the toolbar's right-click menu, there is no mechanism to re-display it.
Workaround: Close and reopen the vSphere Client.

Joining two vCenter Server instances fails with an error message in status.txt about failure to remove VMwareVCMSDS
Joining an existing standalone vCenter Server instance to a Linked Mode group causes the vCenter Server installer to fail. When this happens, vCenter Server does not start on the machine where you are performing the installation. Also, messages indicating problems with LDAP connectivity or the LDAP service being unreachable are written to the /status.txt file, where
is the temporary directory defined on your Windows system. To diagnose this problem, open the status.txt file and look for the following message: [2009-03-06 21:44:55 SEVERE] Operation "Join instance VMwareVCMSDS" failed: : Action: Join Instance Action: Removal of standalone instance Action: Remove Instance Problem: Removal of instance VMwareVCMSDS failed: The removal wizard was not able to remove all of the components. To complete removal, run "Adamuninstall.exe /i: " after resolving the following error:
Folder ' \VMwareVCMSDS' could not be deleted. The directory is not empty.

Workaround: Perform the following steps:
1. From a command prompt with administrator-level privileges, change directories to the vCenter Server installation directory.
2. Delete the VMwareVCMSDS directory.
3. Recover the local LDAP instance by typing jointool.bat recover.

vCenter Server 4.0 becomes unresponsive in large environments if managing ESX Server 3.5 hosts prior to ESX 3.5 patch 10
vCenter Server 4.0 can become unresponsive in large environments after 30 days if it manages any ESX Server 3.5 hosts prior to ESX Server 3.5 patch 10.
Workaround: Upgrade to ESX Server 3.5 Update 4 if you are running ESX Server 3.5 with vCenter Server 4.0.

Networking problems and errors might occur when analyzing machines with VMware Guided Consolidation
When a large number of machines are under analysis for Guided Consolidation, the vCenter Collector Provider Services component of Guided Consolidation might be mistaken for a virus or worm by the operating system on which the Guided Consolidation functionality is installed. This occurs when the analysis operation encounters a large number of machines that have invalid IP addresses or name resolution issues. As a result, a bottleneck occurs in the network and error messages appear.
Workaround: Do not add machines for analysis if they are unreachable. If you add machines by name, make sure the NetBIOS name is resolvable and reachable. If you add machines by IP address, make sure the IP address is static.

Multiple SSL warning messages appear when vCenter Server systems are joined in a Linked Mode group
If multiple vCenter Server systems are joined in a Linked Mode group and do not use SSL certificates for authentication, multiple SSL warnings might be displayed in the vSphere Client when you log in.
Workaround: Address each warning individually. Select the Always ignore this certificate option on each host. You must configure vCenter Servers to use SSL certificates.

No vSphere Web Access connection to vCenter Server when you change the HTTP port from vSphere Client
When you connect to vCenter Server with the vSphere Client, you can change the HTTP port of the vCenter Server (Administration > vCenter Server Settings > Web Service > Ports > HTTP). This port allows you to connect to vCenter Server by using vSphere Web Access. If you change the HTTP port value, vSphere Web Access might become unavailable to all users.
Workaround: Complete the following steps to change the port settings in the vSphere Web Access configuration files so that it can receive connections on the port you specified.

Log in to your vCenter Server machine and open the following directory:

C:\Program Files\VMware\Infrastructure\tomcat\webapps\ui\jslib-1.0.157180 \modules\com.vmware.webaccess.app_1.0.0

If you used a directory other than C:\Program Files\ when you installed vCenter Server, use the appropriate directory path.
Open the WebAccess.properties file and update the login_url value with the port value you specified in vSphere Client as follows:

Current value: http://localhost:80/sdk
New value: http://localhost:[new_port]/sdk
Right-click My Computer and select Manage.
Under Services and Applications, select Services, locate VMware VirtualCenter Management Webservices, and restart the service.

NOTE: Restarting the service will impact connections to vCenter Server systems in Linked Mode and existing vSphere Web Access connections.
Clear your browser cache.
Use http://localhost: /ui to connect to vCenter Server through vSphere Web Access.

vSphere Client displays inaccurate information in the General section of the Summary tab for hosts
Under heavy load, the right-hand panel in the vSphere Client might fail to refresh and displays an inaccurate information in the General section.
Workaround: You may need to refresh the vSphere Client manually by selecting a different host, and then select the first host again.

For large vCenter Server inventories, when you open the vSphere Client in Linked Mode with the inventories of all vCenter Server systems fully expanded, the vSphere Client might be non responsive for several minutes
Fully expanded vSphere Client inventories are those with clusters and datacenters expanded. If you close the vSphere Client after fully expanding the inventories, the next time you open it, the expanded inventory view is loaded. As a result, the vSphere Client might become non responsive for several minutes, depending on the number of vCenter Server systems and the number of objects in each vCenter Server system's inventory. The vSphere Client will start responding after it loads all inventory objects.
Workaround: As a best practice, do not to expand the nodes of every vCenter Server system in the inventory of a Linked Mode group. Collapse the nodes before you close the vSphere Client to avoid loading the expanded nodes at start-up.

Hardware health service does not support hosts earlier than ESX Server 3.5 Update 4
Hardware health alarms are not triggered for ESX Server 3.5 Update 3 and earlier. When you view the vSphere Client Hardware Status tab directed at an ESX Server 3.5 Update 3 host and earlier, a message appears stating that hardware health monitoring requires ESX Server 3.5 Update 4 or later, or ESXi.
Workaround: To support hardware health monitoring for ESX Server 3.5 Update 3 or earlier, apply ESX Server 3.5 patch 11 (ESX350-200901407-BG), which is contained in ESX Server 3.5 Update 4.

Disabled alarms for inventory objects are enabled if vCenter Server is restarted
If an alarm for an inventory object, such as a hosts, virtual machine, datastore, and so on, is disabled in vCenter Server and vCenter Server is restarted, the alarms are enabled after the vCenter Server restart is complete.
Workaround: Disable the alarms on the appropriate inventory objects when vCenter Server restarts.

Virtual machine templates stored on shared storage become unavailable after Distributed Power Management (DPM) puts a host in standby mode or when a host is put in maintenance mode
The vSphere Client associates virtual machine templates with a specific host. If the host storing the virtual machine templates is put into standby mode by DPM or into maintenance mode, the templates appear disabled in the vSphere Client. This behavior occurs even if the templates are stored on shared storage.
Workaround: Disable DPM on the host that stores the virtual machine templates. When the host is in maintenance mode, use the Datastore browser on another host that is not in maintenance or standby mode and also has access to the datastore on which the templates are stored to find the virtual machine templates. Then you can provision virtual machines using those templates.

You might encounter a LibXML DLL module load error when you fresh install vSphere CLI on some Windows platforms, such as Windows Vista Enterprise SP1 32bit for the first time

Incorrect links on ESX and ESXi Welcome page
The download links under vSphere Remote Command Line section, vSphere Web Services SDK section, and the links to download vSphere 4 documentation and VMware vCenter on the Welcome page of ESX and ESXi are wrongly mapped.
Workaround: Download the products from the VMware Web site.

On Nexus 1000v, distributed power management cannot put a host into standby
If a host does not have Integrated Lights-Out (iLO) or Intelligent Platform Management Interface (IPMI) support for distributed power management (DPM), that host can still use DPM provided all the physical NICs of the host that are added to Nexus 1000V DVS have Wake-on-LAN support. If even one of the physical NICs is not Wake-on-LAN supported, the host cannot be put into standby by DPM.

Workaround: None.

Virtual Machine Management

VMXNET 3 network adapters are not exported during an OVF export of virtual machines *
When you use VirtualCenter to perform an Open Virtualization Format (OVF) export, virtual machines which have VMXNET 3 network adapters are exported with VMXNET network adapters. This will cause virtual machines from this template to be deployed with VMXNET network adapters instead of VMXNET 3 network adapters. This issue occurs when you connect to the ESX host by using vSphere Client released along with vSphere 4.0 Update 3.

Workaround: None.
Prompts to install a PCI standard PCI-PCI bridge occur after upgrading Windows 2000 virtual machines from hardware version 4 to hardware version 7
When you upgrade a Windows 2000 virtual machine from hardware version 4 to hardware version 7, you might see numerous pop-up messages prompting you to install a PCI standard PCI-PCI bridge. These messages are harmless.
Workaround: Accept all prompts to complete the hardware version upgrade.

Custom scripts assigned in vmware-toolbox for suspend power event do not run when you suspend the virtual machine from the vSphere Client
If you have assigned a custom script to the suspend power event in the Script tab of vmware-toolbox and you have configured the virtual machine to run VMware Tools scripts when you perform the suspend scripts, then the custom scripts are not run when you suspend the virtual machine from the vSphere Client.
Workaround: None

Automatic VMware Tools upgrade on guest power on reboots the guest automatically without issuing a reboot notification
If you select to automatically update VMware Tools on a Windows Vista or Windows 2008 guest operating system, when the operating system powers on, VMware Tools is updated and the guest operating system automatically reboots without issuing a reboot notification message.
Workaround: None

Cloning virtual machines with customization might result in a dialog box for Sysprep file information
When you clone a virtual machine with customization, the cloning process might not finish and a Sysprep dialog box might prompt you for additional files.
Workaround: Perform the following steps:
1. Note the list of missing files that Windows mini-setup cannot find.
2. Copy the required files (for example, c_20127.nls) from the source machine to the Sysprep install files folder, c:\sysprep\i386. The files that Sysprep prompts for are usually in the following location on the virtual source machine: C:\Windows\system32.
3. Perform the cloning with customization.
Note: The Sysprep directory is removed after the virtual machine is started and customization is completed.

Virtual machines running a Windows NT guest operating system require a reinstall of the network adapter driver after upgrading virtual hardware from version 4 to version 7
After upgrading the virtual hardware on a Windows NT guest operating system, the virtual machine is unable to get an IP address because Windows NT does not fully support plug-and-play specification.
Workaround: After upgrading virtual hardware from version 4 to version 7 on a Windows NT virtual machine, reinstall the network adapter driver by following the steps below.
1. Right-click Network Neighborhood and select Properties.
2. Select the Adapters tab.
3. Remove the existing adapter.
4. Add a new adapter.
5. For an AMD PCNet driver, select AMD PCNET Family Ethernet adapter and specify the path as C:\winnt\system32.
  For a vmxnet driver, click Have disk and specify path as C:\Program Files\VMware\VMware Tools\Drivers\vmxnet\.
6. Reboot the virtual machine.

An IDE hard disk added to a hardware version 7 virtual machine is defined as Hard Disk 1 even if a SCSI hard disk is already present
If you have a hardware version 7 virtual machine with a SCSI disk already attached as Hard Disk 1 and you add an IDE disk, the virtual machine alters the disk numbering. The IDE disk is defined as Hard Disk 1 and the SCSI disk is changed to Hard Disk 2.
Workaround: None. However, if you decide to delete one of the disks, do not rely exclusively on the disk number. Instead, verify the disk type to ensure that you are deleting the correct disk.

Reverting to snapshot might not work if you cold migrate a virtual machine with a snapshot from an ESX/ESXi 3.5 host to an ESX/ESXi 4.0 host
You can cold migrate a virtual machine with snapshots from an ESX/ESXi 3.5 host to ESX/ESXi 4.0 host. However, reverting to a snapshot after migration might not work.
Workaround: None

The vCenter Server fails when the delta disk depth of a linked virtual machine clone is greater than the supported depth of 32
If the delta disk depth of a linked virtual machine clone is greater than the supported depth of 32, the vCenter Server fails and the following error message appears:
Win32 exception: Stack overflow

In such instances, you cannot restart the vCenter Server unless you remove the virtual machine from the host or clean the vCenter Server database. Consider removing the virtual machine from the host rather than cleaning the vCenter Server database, because it is much safer.

Workaround: Perform the following steps:
1. Log in to the vSphere Client on the host.
2. Display the virtual machine clone in the inventory.
3. Right-click the virtual machine and choose Delete from Disk.
4. Restart the vCenter Server.
Note: After you restart the vCenter Server, if the virtual machine is listed in the vSphere Client inventory and the Remove from Inventory option is disabled in the virtual machine context menu, you must manually remove the virtual machine entry from the vCenter database.

Creating a new SCSI disk in a virtual machine can result in an inaccurate error message
When you create a new SCSI disk in a virtual machine and you set the SCSI bus to virtual, an error message is issued with the following line:

Please verify that the virtual disk was created using the "thick" option.

However, thick by itself is not an option. The option should be eagerzeroedthick.

Workaround: Using the command line, create the SCSI disk with the vmkfstools command and the eagerzeroedthick option.

The Installation Boot options for a virtual machine are not exported to Open Virtualization Format (OVF)
When you create an OVF package from a virtual machine that has the Installation Boot option enabled, this option is ignored during export. As a result, the OVF descriptor is missing the InstallSection element, which provides information about the installation process. When you deploy an OVF package, the InstallSection element is parsed correctly.
Workaround: After exporting the virtual machine to OVF, manually create the InstallSection parameters in the OVF descriptor. If a manifest (.mf) file is present, you must regenerate it after you modify the OVF descriptor.

Example:Specifies that an install boot is needed.

The inclusion of the InstallSection parameters in the descriptor informs the deployment process that an install boot is required to complete deployment. The ovf:initialBootStopDelay attribute specifies the boot delay.

See the OVF specification for details.

A virtual machine cloned from a snapshot of a virtual machine with an LSI SAS controller might be erroneously configured with a BusLogic controller
If you take a snapshot of a virtual machine with an LSI SAS controller and then clone a virtual machine from the snapshot, the virtual machine that was cloned from the snapshot might have BusLogic controller configured in the virtual machine properties instead of LSI SAS controller.
Workaround: After cloning a virtual machine from a snapshot of a virtual machine with an LSI SAS controller, check the controller type for the cloned virtual machine in the Snapshot.config property. Reconfigure the controller type for the cloned virtual machine if necessary.

Virtual machine fails to boot after adding (iLO) virtual CD-ROM without media as a SCSI device *
After adding Integrated Lights-Out (iLO) virtual CD-ROM without media to the virtual machine as a SCSI device, virtual machine fails during booting when trying to boot from the virtual CD-ROM.

The three workarounds for this issue are:
- Ensure that iLO virtual CD-ROM always contains media connected when any virtual machine uses it.
- If virtual CD-ROM is not used for guest operating system installation in the virtual machine, change the boot order in the virtual machine BIOS to list hard disk, floppy disk, and NIC above CD-ROM.
- Avoid the usage of iLO virtual CD-ROM. ESX can connect both local and remote CD-ROM devices and ISO images to the virtual machines, without enforcing the restriction of only one CDROM device being exposed by iLO on a system.

vMotion and Storage vMotion

Reverting to a snapshot might fail after reconfiguring and relocating the virtual machine
If you reconfigure the properties of a virtual machine and move it to a different host after you have taken a snapshot of it, reverting to the snapshot of that virtual machine might fail.
Workaround: Avoid moving virtual machines with snapshots to hosts that are very different (for example, different version, different CPU type, etc.)

Using Storage vMotion to migrate a virtual machine with many disks might time out
A virtual machine with many virtual disks might be unable to complete a migration with Storage vMotion. The Storage vMotion process requires time to open, close, and process disks during the final copy phase. Storage vMotion migrations of virtual machines with many disks might time out because of this per-disk overhead.
Workaround: Increase the Storage vMotion fsr.maxSwitchoverSeconds setting in the virtual machine configuration file to a larger value. The default value is 100 seconds. Alternatively, at the time of the Storage vMotion migration, avoid running a large number of provisioning operations, migrations, power on, or power off operations on the same datastores the Storage vMotion migration is using.

Storage vMotion does not support source RDM conversion to target NFS volumes
Disk-only Storage vMotion fails for virtual mode RDMs when you convert the disks to flat/sparse format on NFS volumes.
Workaround: Perform the following steps to migrate virtual mode RDMs to NFS volumes:
1. Use Storage vMotion to convert an RDM virtual machine disk to disk type flat/sparse using intermediate an SAN, local, or iSCSI volume.
2. Use Storage vMotion to relocate the converted disks from the SAN, local, or iSCSI volume to an NFS volume.

Storage vMotion of NFS volume may be overridden by NFS server disk format
When you use Storage vMotion to migrate a virtual disk to an NFS volume or perform other virtual machine provisioning that involves NFS volumes, the disk format is determined by the NFS server where the destination NFS volume resides. This overrides any selection you made in the Disk Format menu.
Workaround: None

If ESX/ESXi hosts fail or reboot during Storage vMotion, the operation can fail and Virtual machines might become orphaned
If hosts fail or reboot during Storage vMotion, the vMotion operation can fail. The destination virtual machine's virtual disks might show up as orphaned in the vSphere inventory after the host reboots. Typically, the virtual machine's state is preserved before the host shuts down.
If the virtual machine does not show up in an orphaned state, check to see if the destination VMDK files exist.

Workaround: You can manually delete the orphaned destination virtual machine from the vSphere inventory. Locate and delete any remaining orphaned destination disks if they exist on the datastore.

Storage vMotion conflicts with remote CD/DVD and floppy disk device connections
CD/DVD and floppy remote backup devices are not supported with Storage vMotion. However, when you perform Storage vMotion on a powered-on virtual machine hosted by ESX/ESXi 4.0, the toolbar icon for connecting and disconnecting CD/DVD and floppy devices remains enabled, allowing you to add these devices while Storage vMotion is in progress even though this might cause failures.
Workaround: Before initiating Storage vMotion, disconnect all remote CD/DVD and floppy devices attached to the virtual machine by clicking the CD/DVD and floppy device connect/disconnect icon.

Storage vMotion failure mode can result in power off of virtual machine
When Storage vMotion is used on an ESX/ESXi 4.0 host, if moving the data fails due to a transient error (for example: out of memory), Storage vMotion might not complete successfully, migration performance may degrade, or the source virtual machine may power off.
Workaround: Power on the virtual machine.

Storage vMotion on ESX/ESXi 3.5 hosts does not display correct disk type if disk type is changed during Storage vMotion
The Storage vMotion wizard presents an option to convert disk type (from thick to thin or from thin to thick) for virtual machines on any ESX/ESXi host version. After a disk is converted and Storage vMotion is complete, the disk type is not reflected properly for ESX/ESXi 3.5 hosts. The vSphere Client still reflects the old disk type.
Workaround: Power off the virtual machine, un-register it, and then re-register it.

Virtual machines stored on a local datastore are not migrated off of the host when the host is placed in maintenance mode
Virtual machines stored on a local datastore are not migrated off of the host when the host is placed in maintenance mode.
Workaround: Manually move virtual machine on local datastores to another host if they need to remain available while their current host is in maintenance mode.

Using Storage vMotion to relocate a virtual machine back to its source volume might result in an insufficient disk space error
When you use Storage vMotion to move a virtual machine to another datastore and then back to its source volume, the vSphere Client does not immediately refresh the size of the source datastore, resulting in an error.
Workaround: Refresh the datastore in the vSphere Client. If the reported size of the datastore does not change after one attempt, wait for 30 minutes and refresh again.

Migrating an ESX 3.x virtual machine with snapshots in powered-off or suspended state to another datastore might cause data loss and make the virtual machine unusable (KB 1020709)

Rebooting ESX/ESXi when Storage vMotion is in progress might create a duplicate virtual machine with the same name (KB 1023182)

VMware High Availability and Fault Tolerance

Failover to VMware FT secondary virtual machine produces error message on host client
When VMware Fault Tolerance is failing over to a secondary virtual machine, if the host chosen for the secondary virtual machine has recently booted, the host client sees this attempt as failing and displays the following error message:
Login failed due to a bad username or password.

This error message is seen because the host has recently booted and it is possible that it has not yet received an SSL thumbprint from the vCenter Server. After the thumbprint is pushed out to the host, the failover succeeds. This condition is likely to occur only if all hosts in an FT-enabled cluster have failed, causing the host with the secondary virtual machine to be freshly booted.

Workaround: None. The failover succeeds after a few attempts.

Changing the system time on an ESX/ESXi host produces a VMware HA agent error
If you change the system time on an ESX/ESXi host, after a short time interval, the following HA agent error appears:
HA agent on <server> in <cluster> in <data center> has an error.

This error is displayed in both the event log and the host's Summary tab in the vSphere Client.

Workaround: Correct the host's system time and then restart vpxa by running the service vmware-vpxa restart command.

Trying to change the disk format of an FT-enabled virtual machine while migrating it across datastores results in a fault
If you attempt to change the disk format of a powered-off, FT-enabled virtual machine while migrating it across datastores, the vSphere Client displays an InvalidArgument error message indicating that the operation has failed. The correct behavior is for the vSphere Client to disable the option to change the disk format.
Workaround: When you relocate an FT-enabled virtual machine to another datastore, select the Same format as source as the default option.

Virtual Machine Monitoring feature in VMware HA is not supported for ESX or ESXi releases prior to ESX 3.5 U3
With VMware HA enabled for a cluster managed by vCenter Server 4.0, the VM Monitoring feature does not function correctly on ESX or ESXi hosts earlier than ESX Server 3.5 Update 3 and might cause false virtual machine failovers.
Workaround: Disable the VM Monitoring feature for such virtual machines or upgrade the ESX/ESXi host to ESX Server 3.5 Update 3 or later.

Non responsive Secondary VMs or copies of virtual machines with possibly different names might remain in the host inventory if there is an interruption when turning on Fault Tolerance
If you have a virtual machine on which VMware HA is enabled and you turn on Fault Tolerance, a non responsive Secondary VM might be added to the cluster's inventory, or you might end up with multiple copies of the virtual machine with different names. This situation occurs if the destination ESX/ESXi host of the Secondary VM loses connectivity to its managing vCenter Server through a reboot, power loss, or disconnection from the network while the secondary copy is being created and might result in incomplete configuration settings on the Secondary VM.
Workaround: Delete the non responsive Secondary VM from the vCenter Server inventory.

Secondary VM remains in inventory after Fault Tolerance has been turned off for Primary VM
In some rare cases, selecting Turn Off Fault Tolerance in the vSphere Client for a Primary VM succeeds but the associated Secondary VM object is left in the inventory. This occasionally happens when a failover operation has just occurred and the new Secondary VM has not yet been started. This does not cause any serious consequences because the Secondary VM's files should have already been deleted..
Workaround: Manually delete the Secondary VM.

Configuring VMware High Availability (HA) on a heavily loaded system might result in an error message
If you are enabling HA on a host that is experiencing a heavy load from its guest virtual machines, HA configuration might be interrupted for the host and an error message is displayed:
HA Agent on the host failed
Workaround: Reconfigure HA for the host, preferably after reducing the load either by powering off virtual machines or by migrating them to another host in the cluster using vMotion.

Suspended virtual machines with independent nonpersistent disks do not failover on VMware HA hosts
If you have suspended or powered off virtual machines on a host that has VMware HA enabled and if the virtual machine disks are configured to be independent and nonpersistent, failover does not happen. Those disks are not migrated to another host if the host fails, is powered off, or is placed in Maintenance Mode. Migrating these virtual machines is currently not supported on HA because the machines are not compatible with any other host in the cluster.
Workaround: Un register the virtual machine and register it on a compatible host.

VMware HA might report misleading timeout errors when powering on or failing over a host with many VMs
VMware HA timeout errors might appear a few minutes after powering on or migrating (using VMware HA) a host with many VMs (more than 70). This timeout error disappears when most of the VMs are powered on.
Workaround: They can be ignored.

VMware Fault Tolerance does not support IPv6 addressing
If the VMkernel NICs for Fault Tolerance (FT) logging or vMotion are assigned IPv6 addresses, enabling Fault Tolerance on virtual machines fails.

Workaround: Configure the VMkernel NICs using the IPv4 addressing.

Hot-plugging of devices is not supported when FT is disabled on virtual machines
The hot-plugging feature is not supported on virtual machines when VMware Fault Tolerance is enabled or disabled on the virtual machines. You must turn off Fault Tolerance temporarily before you hot-plug a device. After hot-plugging, you can turn-on the FT. But after a hot-removal of a device, you should reboot the virtual machine to turn-on the FT.

VMware Tools

Windows Server 2008 R2 64-bit IP virtualization might not work on vSphere 4.0 Update 1 *
IP virtualization, which allows you to allocate unique IP addresses to RDP sessions might not work on a Windows 2008 R2 Terminal Server running on vSphere 4.0 Update 1. However, IP virtualization works when you configure a physical Windows 2008 R2 Terminal Server, or when you run a Windows 2008 R2 virtual machine on XenServer 5.5 Update 2 Dell OEM Edition. This issue might occur if you install VMware Tools after installing Remote Desktop services.

Workaround: Choose custom installation for installing VMware Tools, and remove VMCI from the list of drivers that should be installed.
Virtual machine snapshots stop responding when certain conditions apply
Attempts to take a virtual machine snapshot might result in the display of the in progress status when all of the following conditions apply:
- The Snapshot the virtual machine’s memory option is not selected.
- The quiesce guest file system option is selected.
- A third-party VSS (Volume Shadow copy Service) provider is installed
In such cases, the in progress status continues to be displayed until the task display times out. Moreover, the process continues, preventing other snapshots from being taken.

VMware Tools installation fails to start the guest operating system daemon on Red Hat Enterprise Linux 4 64-bit guests with the 32-bit glibc-common package installed (KB 1023185)

Top of Page

VMware ESX 4.0 Update 3 Release Notes

What's New

Earlier Releases of ESX 4.0

Before You Begin

ESX, vCenter Server, and vSphere Client Version Compatibility

Hardware Compatibility

Documentation

Installation and Upgrade

Upgrading VMware Tools

Upgrading or Migrating to ESX 4.0 Update 3

Updated RPMs and Security Fixes

Patches Contained in this Release

Resolved Issues

Backup

CIM and API

Guest Operating System

Miscellaneous

Networking

Storage

Upgrade and Installation

Virtual Machine Management

vMotion and Storage vMotion

VMware Tools

Known Issues

Backup

CIM and API

Guest Operating System

Internationalization

Licensing

Miscellaneous

Networking

Server Configuration

Storage

Supported Hardware

Upgrade and Installation

vCenter Server, vSphere Client, and vSphere Web Access

Virtual Machine Management

vMotion and Storage vMotion

VMware High Availability and Fault Tolerance

VMware Tools

Support Resources