VMware ESX 4.0 Update 2 Release Notes
ESX 4.0 Update 2 | 10 Jun 2010 | Build 261974
VMware Tools | 10 Jun 2010 | Build 261974
Last Document Update: 28 Feb 2011 |
These release notes include the following topics:
What's New
The following information provides highlights of some of the enhancements available in this release of VMware ESX:
- Enablement of Fault Tolerance functionality for Intel Xeon 56xx Series processors – vSphere 4.0 Update 1 supports the Intel Xeon 56xx Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel Xeon 56xx Series processors.
- Enablement of Fault Tolerance functionality for Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors – vSphere 4.0 Update 1 supports the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors.
- Enablement of IOMMU functionality for AMD Opteron 61xx and 41xx Series processors – vSphere 4.0 Update 1 supports the AMD Opteron 61xx and 41xx Series processors without input/output memory management unit (IOMMU). vSphere 4.0 Update 2 enables IOMMU functionality for the AMD Opteron 61xx and 41xx Series processors.
- Enhancement of the esxtop and resxtop utility – vSphere 4.0 Update 2 includes an enhancement of the performance monitoring utilities, esxtop and resxtop. The esxtop/resxtop utilities now provide visibility into the performance of NFS datastores in that they display the following statistics for NFS datastores: Reads/s, writes/s, MBreads/s, MBwrtn/s, cmds/s, GAVG/s (guest latency).
- Additional guest operating system support – ESX/ESXi 4.0 Update 2 adds support for Ubuntu 10.04. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.
Resolved Issues – In addition, this release delivers a number of bug fixes that have been documented in the Resolved Issues section.
Top of Page
Prior Releases of ESX 4.0
Features and known issues from prior releases of ESX 4.0 are described in the release notes for each release. To view release notes for prior 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 previous 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 on 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 2. 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 on installing and configuring ESX and vCenter Server.
After successful installation, several configuration steps are essential. In particular, some licensing, networking, and security configuration is necessary. Refer to the following guides in the vSphere documentation for guidance on these configuration tasks.
Future releases of VMware vSphere might not support VMFS version 2 (VMFS2). VMware recommends 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. Consider installing vCenter Server on a 64-bit Windows operating system. If you have VirtualCenter 2.x installed, see the vSphere Upgrade Guide for instructions on 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 2 requires a VMware Tools upgrade. VMware Tools is a suite of utilities that enhances the performance of the virtual machine’s guest operating system. Refer to the VMware Tools Resolved Issues for a list of issues resolved in this release of ESX related to VMware Tools.
The VMware Tools RPM installer, which is available on the VMware Tools ISO image for Linux guest operating systems, has been deprecated and will be removed in a future ESX release. VMware recommends using 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 2
ESX 4.0 Update 2 offers the following options for upgrading:
- vSphere Host Update Utility – For standalone ESX 3.x hosts. A standalone host is an ESX/ESXi host that is not managed by vCenter Server. See the vSphere Upgrade Guide for more information about upgrades using vSphere Host Update Utility.
- VMware vCenter Update Manager – For ESX/ESXi hosts that are managed by vCenter Server. See the VMware vCenter Update Manager Administration Guide for more information.
- esxupgrade.sh script – For ESX 3.x hosts that do 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) – The vihostupdate command of vSphere CLI applies software updates to ESX/ESXi 4.0 hosts and installs and updates ESX/ESXi extensions such as VMkernel modules, drivers, and CIM providers. See the vSphere Upgrade Guide for more information.
- esxupdate command-line utility – For ESX only. It applies software updates to ESX 4.0.X hosts. See the Patch Management Guide for details.
Several upgrade tools that were supported in previous ESX 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. vSphere Host Update Utility and VMware Update Manager are the only tools that are supported for performing upgrades from ESX 3.5.x to ESX 4.0.
Supported Upgrade Paths for Host Upgrade to ESX 4.0 Update 2:
Upgrade Type |
ESX Server 3.5
Includes:
Update 1
Update 2
Update 3
Update 4
Update 5
Update 5a |
ESX 4.0
|
ESX 4.0
Update 1 |
ISO Image |
Yes |
No |
No |
Offline-bundle for ESX 4.0 Update 2 |
No |
Yes |
Yes |
Notes:
- Supported approaches to upgrade using an ISO image are vSphere Host Update Utility 4.0 Update 2, vCenter Update Manager 4.0 Update 2, and esxupgrade.sh. See Performing an offline upgrade from ESX 3.x to ESX 4.x (KB 1009440) . For more details, see vSphere Upgrade Guide.
- Supported approaches to upgrade using the ESX 4.0 Update 2 offline-bundle are the vihostupdate command of vSphere CLI and the esxupdate command line utility. For more details, refer to vSphere Upgrade Guide and Patch Management Guide.
- For upgrading ESX Server 3.0.x, upgrade first to any higher version of ESX Server 3.5.x , and then upgrade to ESX 4.0 Update 2 by using an ISO image. See any 3.5.x Upgrade Guide, such as the following Upgrade Guide: Update 2 and later for
ESX Server 3.5, ESX Server 3i version 3.5, VirtualCenter 2.5.
- You can upgrade ESX 2.5.5 to ESX 4.0 Update 2 by moving the virtual machines. See the vSphere Upgrade Guide.
- For upgrading the ESX 4.0 host to ESX 4.0 Update 2 by using online patches and vCenter Update Manager 4.0 Update 2, see the patches section of these release notes, vSphere Upgrade Guide, and VMware vCenter Update Manager Administration Guide.
Updated RPMs and Security Fixes
For a list of RPMs updated in ESX 4.0 Update 2, see Updated RPMs and Security Fixes. This document does not apply to the ESXi products.
Top of Page
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 or click on the name of a bulletin for more information about the individual bulletins.
Patch Release ESX400-Update02 contains the following individual bulletins:
ESX400-201006201-UG: Updates the VMware ESX 4.0 Core and CIM components
ESX400-201006202-UG: Updates the VMware ESX 4.0 mpt2sas device driver
ESX400-201006203-UG: Updates the VMware ESX 4.0 mptsas, mptspi device drivers
ESX400-201006204-UG: Updates the VMware ESX 4.0 fnic device driver
ESX400-201006205-UG: Updates the ESX 4.0 SCSI/iSCSI driver
ESX400-201006206-UG: Updates the VMware ESX 4.0 ixgbe device driver
ESX400-201006207-UG: Updates the ESX 4.0 Intel igb driver
ESX400-201006208-UG: Updates the ESX 4.0 USB storage component
ESX400-201006209-UG: Updates the ESX 4.0 qlogic SCSI driver
ESX400-201006211-UG: Updates the VMware ESX 4.0 nx-nic device driver
ESX400-201006212-UG: Updates the VMware ESX 4.0 bnx2x device driver
ESX400-201006214-UG: Updates the VMware ESX 4.0 cciss device driver
ESX400-201006215-UG: Updates Driver for VMware ESX 4.0 HP SAS Controllers
ESX400-201006217-UG: Updates the ESX 4.0 python component
ESX400-201006218-UG: Updates the VMware ESX 4.0 SCSI lpfc820 device driver
ESX400-201006219-UG: Updates the VMware ESX 4.0 ATA libata device driver
ESX400-201006220-UG: Updates the ESX 4.0 Megaraid SAS device driver
ESX400-201006221-UG: Updates tzdata
ESX400-201006222-UG: Updates the ESX 4.0 pam_passwdqc rpm
ESX400-201006224-UG: Updates the ESX 4.0 initscripts rpm
ESX400-201006225-UG: Updates the ESX 4.0 Web Access components
ESX400-201006226-UG: Updates the VMware ESX 4.0 EHCI HCD device driver
ESX 4.0 Update 2 also contains all fixes in the following previously released bundles:
Patch Release ESX400-201005001
Patch Release ESX400-201003001
Patch Release ESX 400-201002001
Patch Release ESX 400-200912001
Patch Release ESX400-Update01a
Patch Release ESX400-200909001
Patch Release ESX400-200907001
Patch Release ESX400-200906001
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:
Resolved issues previously documented as known issues are marked with the † symbol.
CIM and API
-
wsman indication subscription is not persistent after a system reboot
In previous releases, wsman indication subscription is not persistent after a system reboot. In this release, wsman indication subscription remains persistent after the system reboot.
-
The Base Server profile definition does not conform to standard
To conform with the DMTF Profile Registration DSP1033 standard, Base Server is changed from Antecedent role to Dependent role in the OMC_ReferencedBaseServerProfile class.
-
Issues exist with LSI provider and vmwprovider
The two following issues related to the storelib library have been observed:
- VMware_HHRCAlertIndication classes are not generated after you reboot ESX/ESXi hosts.
- IR card storelib indication displays incorrect timestamp settings.
The LSI storelib library has been updated to resolve these issues.
-
Failure status phrase in Health Status tab of vSphere Client replaced
In this release, to describe the power supply Health Status in the Health Status tab of the vSphere Client, the wording "Failure detected" is replaced with the wording "Failure status."
-
In previous ESX 4.0 releases, Small-Footprint CIM Broker daemon (sfcbd) trace is not enabled
This issue is resolved in this release. The sfcbd trace is enabled by default in ESX 4.0 Update 2.
Guest Operating System
-
Multiple DNS suffixes are not applied correctly after image customization of Linux distributions †
DNS suffixes are automatically appended when a Linux distribution tries to resolve a DNS domain name. When more than one DNS suffix is customized, only the last DNS suffix is applied. Depending on the Linux distribution, not all customized DNS suffixes appear in the Linux distribution user interface.
-
The mouse wheel might not scroll up in FreeBSD virtual machines
On the console of the FreeBSD virtual machine the scroll up operation cannot be performed by using the mouse wheel.
This issue is resolved in this release.
-
Virtual machines running 64-bit Windows Server 2003 or 64-bit Windows XP guest operating systems might report an incorrect CPU frequency
The CPU frequency reported by 64-bit Windows 2003 and 64-bit Windows XP guest operating systems when run in a virtual machine might be inaccurate. In the virtual machine, QueryPerformanceCounter might run at a rate that is higher than the frequency reported by QueryPerformanceFrequency.
This issue is resolved in this release.
-
Wake-on-LAN does not work with the e1000 vNIC on newer Windows guests †
For ESX/ESXi hosts, the Wake-on-LAN feature (turning on a host with a network message) is not available with the e1000 vNIC on certain Windows guests. Specifically, Windows Vista and later and 64-bit Windows versions do not work.
-
RHEL 5.3 virtual machine console might display a black screen after being resumed from hibernation mode
An issue with the SVGA driver might cause the console of RHEL 5.3 virtual machines to display a black screen after the virtual machine is resumed from hibernation mode.
This issue is resolved in this release.
-
VMware Tools does not install Guest SDK DLLs in system32 or SysWOW64
On Windows guest operating systems, VMware Tools does not install Guest SDK DLLs (vmGuestLib.dll and vmGuestLibJava.dll) in the system directories (system32 or SysWOW64). This issue is resolved in this release.
-
Windows virtual machines with VMXNET3 adapter might stop responding after they are resumed from the standby mode
An issue with the VMXNET3 driver might cause Windows virtual machines to stop responding after they are resumed from standby mode.
This issue is resolved in this release.
-
FreeBSD 7.2 virtual machine console is scrambled and unusable without VMware Tools installed
The console of FreeBSD 7.2 virtual machine is scrambled and unusable if VMware Tools is not installed.
This issue is resolved in this release.
-
On Linux guest operating systems, partition information does not appear when it is formatted with the fourth extended file system (ext4)
Partitions formatted as ext4 might not appear in the Shrink tab of the VMware Tools Properties dialog box. On Linux systems, you access the VMware Tools Properties dialog box by running the following command: /usr/bin/vmware-toolbox &. The ext4 file system is the default file system for certain Linux operating systems, such as Ubuntu 9.10.
This issue is resolved in this release.
- Updated:
PAE-enabled SMP Windows 2000 virtual machines stop responding
A Physical Address Extension (PAE) enabled multiprocessor Windows 2000 virtual machine might stop responding on reboot, report STOP Error, or fail randomly.
This issue is resolved in this release.
-
Guest operating systems that lack an Advanced Programmable Interrupt Controller (APIC) can cause a monitor panic
When a guest operating system lacks an APIC and the virtual machine configuration file does not disable APIC, the virtual machine might stop responding when it resumes from the S1 sleep state.
This issue is resolved in this release.
-
An issue in the timer emulation causes timer interrupts to be delivered to the guest operating system at an excessive rate
This issue has been observed after a vMotion migration when a virtual machine has been up for a relatively long time, such as for one hundred days.
This issue is resolved in this release.
-
Rebooting certain Linux guest operating systems might cause the virtual machine to power off
When a virtual machine with a Linux guest operating system has been running for 30 days or more, rebooting the guest might cause the virtual machine to power off. In such a case, an error message similar to the following is logged in the vmware.log file:
Jun 10 09:57:40.347: vcpu-0| MONITOR PANIC: vcpu-0:VMM fault: regs=0x2f94, exc=0, eip=0x84c91
This issue is resolved in this release.
Internationalization
-
VMware Tools installation might fail on Linux, Solaris, or FreeBSD virtual machines that use unsupported character encodings such as EUC_JP Japanese
If Linux, Solaris, or FreeBSD virtual machines use character encodings that are not supported, such as EUC_JP Japanese, the install process of VMware Tools on the virtual machines might fail.
This issue is resolved in this release. Starting with this release, you can install and run VMware Tools with native character encodings on Linux, Solaris, and FreeBSD virtual machines.
Miscellaneous
-
An ESX/ESXi host or a virtual machine's guest operating system might fail to operate if running multi-threaded applications using VMCI Sockets SDK †
A known issue with the VMCI Sockets library can cause a host or guest operating systems to fail to operate if they are running multi-threaded applications that use the VMCI Sockets SDK.
-
Help menu items appear inactive or clicking other links for Help results in an error †
In vSphere Client installations on machines running non-English, non-Japanese, non-German, and non-Simplified Chinese Windows operating systems, Help menu items appear inactive. In addition, if you click other links or buttons for Help within the vSphere Client the following error message appears:
Missing help file
-
The esxtop and resxtop utilities do not display various logical CPU power state statistics
This issue is resolved in this release. A new Power screen displays logical CPU statistics with the esxtop utility (on ESX) and resxtop utility (on ESX and ESXi). To switch to the Power screen, press y at the esxtop or resxtop screens.
-
Preserve file access permissions when copying files between POSIX operating systems
The CopyFileFromHostToGuest() and CopyFileFromGuestToHost() functions of the VIX C API do not preserve any permission bits when copying a file between the host and guest operating systems. The permissions on the destination file are set to the owner's default values, which typically allow only read and write by the owner.
For example, if the execute bit is set for the file owner on the Linux host, and you use CopyFileFromHostToGuest() to copy the file to a Linux guest operating system, the copy in the guest operating system has the execute bit cleared.
This release fixes the issue of not preserving file access permissions when files are copied from Windows or Linux hosts to guest operating systems or from guest operating systems to Windows or Linux hosts.
-
The time on certain systems becomes inaccurate with the start of daylight saving time (DST) observation
Updated tzdata package (tzdata-2009u) provided in this release addresses the changes in daylight saving time (DST) observation for several countries and regions, such as affecting portions of Antarctica, Argentina, Bangladesh, Cuba, Egypt, Fiji, Morocco, Pakistan, Palestine, Russia, Syria, and Tunisia.
-
Missing return statements in the user world copy utility can lead to memory corruption or server unresponsiveness
Missing return statements in the user world copy utility cause double copying of data to the user world buffer. When return statements are missing after the data is copied to the user world buffer once, a second copy writes data to a VMkernel buffer that does not exist. This might lead to memory corruption or server unresponsiveness.
This issue is resolved in this release.
Networking
-
Virtual machines might drop off of a multicast group when they use either the IGMPv1 or IGMPv2 protocol with teamed uplink NICs
The suppression of Internet Group Management Protocol (IGMPv1 or IGMPv2) membership reports might result in the virtual machines dropping off the multicast group. This dropping of virtual machines occurs when the NIC teaming policy is set to Load Balancing Policy Source Port: Id or Source MAC Address.
This issue is resolved in this release.
-
Speed and duplex settings for a NIC might not be retained after ESX/ESXi server reboots
When the speed and duplex settings for a NIC are manually set and the ESX/ESXi host is rebooted, the values set for the speed and duplex settings might not be retained. After reboot, the network adapter might auto-negotiate its speed and duplex settings.
This issue is resolved in this release.
-
Network setup script to configure the network without using esxcfg-* commands
Starting with this release, a network setup script is available in the vmware-esx-script RPM and is installed at /usr/sbin/console-setup. This script can be used to configure the ESX network interactively without having to run the esxcfg-* commands. With this script you can view the current Vswif configuration information, the current network adapters, the current vSwitch and vDS information, delete a Vswif, and configure the service console network interface.
-
The ring size of the VMXNET3 network interface card is not configurable in Windows guest operating systems
This issue is resolved in this release. Configuration parameters, such as Rx Ring #1 Size, Rx Ring #2 Size, Tx Ring Size, Small Rx Buffers, and Large Rx Buffers are now configurable from Device Manager (a Control Panel dialog box) in Windows guest operating systems.
-
Duplicate multicast packets are generated when the vSwitch has at least two vmnics and promiscuous mode enabled
Consider a vSwitch that has more than one uplink and has the promiscuous mode enabled. Some of the packets that come in from the uplinks that are not currently used by the promiscuous port, are not discarded. This behavior might mislead some applications, such as the CARP protocol instance.
This issue is resolved in this release. Starting with this release the Net.ReversePathFwdCheckPromisc configuration option is provided to explicitly discard all the packets coming in from the currently unused uplinks, for the promiscuous port.
Note: If the value of the Net.ReversePathFwdCheckPromisc configuration option is changed when the ESX instance is running, you need to enable or re-enable the promiscuous mode for the change in the configuration to take effect.
-
In recent firmware versions released by QLogic and NetXen, some ports on the Quad port 1G NICs are not displayed
The issue is mostly seen on HP branded NetXen cards, such as NC375T. The esxcfg-nics -l command (supported on ESX) and the vSphere Client both fail to display some ports on Quad port 1G NICs. These NetXen devices/ports are recognized by the hardware and are listed with the lspci command (supported on ESX). However, the driver fails to create or probe some ports.
This issue is resovled in this release.
The fix addresses how the driver creates devices.
-
Windows guest operating systems earlier than Windows Vista might lose connectivity when used in conjunction with the VMXNET3 virtual network interface card
Network Driver Interface Specification (NDIS) is part of the networking architecture used in Microsoft Windows operating systems. The NDIS transport driver might hold the buffers received by VMXNET3 drivers indefinitely and run out of buffers to receive.
This issue is resolved in this release.
-
Virtual machines connected to a vNetwork Distributed Switch (vDS) might be disconnected after a failover
vDS virtual machine port changes persist the port configuration every five minutes. Because virtual machine port changes are not persisted immediately, virtual machines might lose network connectivity after a failover event if they have been configured to link to a vDS less than five minutes before the failover.
This issue is resolved in this release.
-
vNetwork Distributed Switch (vDS) reports an error when adding a new port even after the setting for the maximum proxy port count is increased
The vDS state and the proxy switch are saved in separate files and are processed independently. When vDS is created, the same maxPorts setting is used for both. However, when you change the maxPorts setting, only the proxy switch configuration is updated. Because vDS continues to use the old maxPorts value, it reports an error when adding the new port because the total number of the proxy ports is greater than the old maxPorts value.
This issue is resolved in this release.
Server Configuration
Storage
-
Removing all snapshots from a virtual machine with the Delete All option can use large amounts of disk space
When you use the Delete All option in Snapshot Manager, the snapshot farthest from the base disk is committed to its parent, causing that parent snapshot to grow. When the commit is complete, that snapshot is removed and the process starts over on the newly updated snapshot to its parent. This continues until every snapshot has been committed.
This method might be relatively slow because data farthest from the base disk might be copied several times. More importantly, this method can aggressively use disk space if the snapshots are large, which is especially problematic if a limited amount of space is available on the datastore. The space issue is troublesome in situations where you might be deleting snapshots explicitly to free up storage.
This issue is resolved in this release. The order of snapshot consolidation has been modified to start with the snapshot closest to the base disk instead of farthest. The end result is that data is not copied repeatedly.
-
Virtual machines that utilize a PVSCSI adapter might stop responding or behave unexpectedly early in the virtual machine boot process
Disks connected using PVSCSI controllers are accessed through both the BIOS and the PVSCSI driver. When you boot a virtual machine from a PVSCSI disk, the BIOS is utilized initially. Under certain conditions, the virtual machine boot process might encounter stale data, resulting in guest operating system misbehavior or an unresponsive guest operating system.
This issue is resolved in this release.
-
The VMW_SATP_DEFAULT_AA plug-in, a Storage Array Type Plug-in, unexpectedly controls all devices from IBM RAID Shared Storage Module
Because VMW_SATP_ALUA plug-ins cannot control IBM RAID SAS Switch Module (RSSM) devices with Target Port Group Support (TPGS) capability, VMW_SATP_DEFAULT_AA plug-ins are able to take this control.
This issue is resolved in this release. Now Storage Array Type Plug-in (SATP) rules allow VMW_SATP_ALUA plug-ins to own RSSM devices with TPGS capability and VMW_SATP_DEFAULT_AA plug-ins to own RSSM devices without TPGS capabiity.
- The vmkiscsi-tool utility does not display login errors
The vmkiscsi-tool utility reads and displays all the attributes of the target except for the login status data. However, troubleshooting without login status data might be complex and cumbersome.
This issue is resolved in this release. The vmkiscsi-tool now lists login errors.
-
The Emulex adapter fails to rediscover the target ports of an HP modular storage array when a reset is performed for a target port on the array
The HP modular storage array has a failover feature that allows the active port to assume the identity of another port including the other port's World Wide Port Name (WWPN). When this happens, the target port has the same destination ID (DID), but a different WWPN. This differentiation causes the driver to mark one of the two target ports as NPR with a port login (PLOGI) that is outstanding while the other target port proceeds normally with the identity it assumed from the first target port.
This issue is resolved in this relase. The fix detects this condition and reissues the PLOGI to correctly rediscover the targets.
-
Redundant messages are issued when data access commands are sent to a drive without media
If a virtual machine accesses a CD drive that does not have a media, the vmware.log file is overloaded with redundant entries similar to the following:
VIDE: ATAPI DMA 0x43 Failed: key 0x2, asc 0x3a, ascq 0x0
This issue is resolved in this release.
-
A journal block free operation failure causes a file block to leak and become inaccessible to the file system driver
The following assertion, which indicates that a block free operation failed, is logged for this issue: WARNING: J3: 1644: Error freeing journal block (returned 0)
for 4ac5183a-d1b537f3-2627-00237dce6676: Lock was not free
This issue is resolved in this release. Journal block leakage no longer occurs because of a block free operation failure.
-
ESX incorrectly handles read lengths that are not 4-byte aligned
When read lengths are not 4-byte aligned, the RPC reply from the ESX host pads the message with bytes to make it 4-byte aligned. This incorrectly fills the SG array with padding bytes, and might cause ESX to stop responding when the SG array does not have space for the padding bytes.
-
Hosts might not detect target LUNs through a Cisco M81KR virtual NIC if the target and host are configured in the IVR zone of a Cisco MDS switch
When a Cisco M81KR virtual interface card is added to a host in an Inter-VSAN Routing (IVR) zone with the target on a Cisco MDS switch, a login attempt to the target might time out and the host might not see the target storage LUNS.
This issue is resolved in this release.
-
Support for SGI InfiniteStorage 4000, 4100, and 4600 storage arrays
This patch provides support for the following storage arrays from SGI: SGI InfiniteStorage 4000, SGI InfiniteStorage 4100, and SGI InfiniteStorage 4600. These SGI controllers are managed by LSI Storage Array Type Plugin of the VMware Native Multipath Plugin (NMP).
-
Dropped frames might be incorrectly reported by Qlogic drivers for fibre channel host bus adapters (HBAs)
Storage arrays returning less data than expected (an underrun condition) are incorrectly reported by the Qlogic driver as having dropped frames with a SCSI status of Busy instead of an underrun condition with the original SCSI status.
This issue is resolved in this release. The Qlogic driver reports SCSI status correctly and does not report that the frames are dropped.
-
For devices using the roundrobin PSP the value configured for the --iops option changes after ESX host reboot
If a device that is controlled by the roundrobin PSP is configured to use the --iops option, the value set for the --iops option is not retained if the ESX host is rebooted.
This issue is resolved in this release.
-
A journal code issue leads to a panic (or OOPS) in the service console of an ESX host
A journal might be aborted in the middle of a truncate or journal restart operation, which might cause a service console panic.
This issue is resolved in this release.
Supported Hardware
-
Event messages from StoreLib of IR cards show incorrect timestamp †
The IndicationTime in the event messages from the StoreLib shows incorrect timestamp for LSI 1078 and 1068E Integrated RAID (IR) controllers.
-
When using vSphere Client to access the console of a virtual machine that uses a NetXen NX3031 network interface controller (NIC), the system fails and displays a purple screen
When the NetXen NX3031 NIC resides on a relatively high memory location (possibly above 512GB), the system becomes unresponsive as it tries to access an address that is out of range. For example, this issue might occur if the system has a physical memory of 96GB but the memory map configuration generates addresses beyond the 512GB memory location.
A message similar to the following is logged before the system becomes unresponsive:
<3>nommu_map_single: overflow a31407ad5a+54 of device mask 7fffffffff
The following is an example of a backtrace of this issue:
0x4100c00e7338:[0x41801d1984bf]nommu_map_single+0x4e stack: 0x0
0x4100c00e7598:[0x41801d26f745]unm_nic_xmit_frame+0x4d8 stack: 0x4100c00e75c8
0x4100c00e7688:[0x41801d1a1609]process_tx_queue+0x874 stack: 0x41000b884600
This issue is resolved in this release.
Upgrade and Installation
-
Installing ESX on a system with more than eight network interface cards (NICs) might cause the system to become unresponsive
When you use the text mode to install ESX on a system that has more than eight NICs, the installer might stop responding and an error similar to the following might be displayed:
An error has occurred during your ESX installation. 'NicSetup' object has no attribute 'scrollDisplay'
This issue is resolved in this release.
-
Changes made to the /etc/syslog.conf file in ESX 4.0 might be overwritten after an upgrade to ESX 4.0 Update 1 †
This issue occurs if the vmkernel entry does not exist in the syslog.conf file in ESX 4.0. If the vmkernel entry does not exist, changes made in the syslog.conf file are overwritten during upgrade. More specifically, during the next update or patch, the lnxcfg post scriptlet replaces the syslog.conf file with a new one.
-
Applying bulletin ESX400-200911201-UG removes LSI library symbolic links †
During the upgrade process for bulletin ESX400-200911201-UG or ESX400-Update01/ESX400-Update01a, the following symbolic links are removed:
/lib/libstorelib.so.2
/lib/libstorelibir.so.2
/lib/libstorelibir-2.so.2
The vmware-esx-lsi RPM is responsible for this behavior. If an application depends on the vmware-esx-lsi RPM, you might need to restore the symbolic links for that application to work again.
-
On QLogic HBAs, the driver cached copy of VPD is corrupted during a flash update †
Performing a flash update using the SANsurfer SCLI or GUI causes the reported QLogic adapter information to be incorrect. The corrupted information might be, but is not necessarily, accompanied by an error message at the completion of the flash update, such as one of the following:
- GUI error message: Unable to update Flash
- SCLI error message: Flash update failed on the HBA
The VPD region of the flash is populated with updated image versions, serial numbers, and other related adapter information during the SANSurfer SCLI or GUI flash update. After an update, the SANSurfer or SCLI utilities display the VPD adapter information incorrectly. Possible erroneous data displayed includes the following:
- Incorrect BIOS/EFI/Fcode versions, or versions with N/A status.
- Incorrect number of HBA adapters. For example, displaying one 2-port HBA as two 1-port HBAs.
-
When upgrading to ESX 4.0 Update 1, the system runs out of space before the upgrade is completed and might become unrecoverable
A problem in the free disk space calculation routine of the RPM tool causes a miscalculation of the available disk space prior to upgrade. If the system runs out of free disk space during an upgrade, the upgrade process might be interrupted, possibly leaving the system in an unrecoverable state.
This issue is resolved in this release.
vCenter Server, vSphere Client, and vSphere Web Access
-
The vSphere Client might take longer than expected to display newly installed extensions in the list of installed extensions †
After extensions are installed, 30-60 seconds pass before newly installed extensions appear in the list of installed extensions.
- VMWare Paravirtual SCSI controller can be used with Suse Linux Enterprise 11 SP1 virtual machines
Starting with vSphere 4.0 Update 2, you can create Suse Linux Enterprise 11 (32-bit) or Suse Linux Enterprise 11 (64-bit) virtual machines with VMware Paravirtual SCSI controller. However, you need to at least have SUSE Linux Enterprise 11 SP1 installed as the guest operating system to include the vmw_pvscsi driver.
For more information about the combination of guest operating system and the ESX releases supported, see the VMware Compatibility Guide.
- 0S/2 virtual machines can have only one virtual processor
Starting with vSphere 4.0 Update 2, when creating virtual machines with OS/2 guest operating system, you cannot select more than one virtual processor.
Virtual Machine Management
-
Legacy vmware-toolbox script tab settings revert to default after VMware Tools upgrade on Linux guest operating systems †
When you upgrade VMware Tools on an ESX Server 3.0.x virtual machine running a Linux guest operating system, existing settings on the vmware-toolbox script tab revert to default settings.
-
Following the suspension and resumption of a virtual machine, attempts to disable the VMXNET3 adapter might fail †
Between suspension and resumption, if the network connection goes into an undefined state, for example, if the port-group name changes, then the virtual network device cannot update the new network connection to the driver. This state prevents the VMXNET3 adapter from being disabled, uninstalled, or updated.
-
A virtual machine might fail to respond upon shutdown
At shutdown, or possibly at other times if certain conditions apply, a vmx process might not respond, causing the respective virtual machine to stop responding.
This issue is resolved in this release.
-
A virtual machine fails to respond or power on when its network interface card (NIC) is attached to a port group with a name that exceeds 50 characters
This issue is resolved in this release. Port group names now cannot be changed to a name that exceeds 50 characters. Previously assigned port group names that exceed 50 characters are not accessible by virtual machines.
vMotion and Storage vMotion
VMware High Availability and Fault Tolerance
-
When a virtual machine running on a NAS datastore is configured to shut down in response to host isolation, the virtual machine might attempt to run simultaneously on two hosts in a network isolation event †
If a virtual machine is configured with the default setting to shut down on host isolation, the virtual machine might fail to respond indefinitely while trying to shut down in the event of a multiple network failure that causes host isolation and the loss of network access to the datastore. HA tries to power off the virtual machine and restart it on another host. Two instances of the virtual machine might appear in the vSphere Client. There is no data corruption, because HA and VMFS correctly control access to the virtual machine's data, but the original virtual machine becomes nonresponsive. You can clear the condition by connecting directly to the host that was isolated and dismissing the question.
VMware Tools
-
Virtual printing components of ThinPrint are automatically installed when you install VMware Tools
Starting with this release, when you install VMware Tools using the custom option, you can deselect ThinPrint to install VMware Tools without installing the virtual components of ThinPrint.
-
Upgrade of VMware Tools breaks Microsoft SQL Server functionality
Some third-party software programs, such as Microsoft SQL Server, don't share atl71.dll. Therefore, the software doesn't increase the .dll reference count during installation. As part a major VMware Tools upgrade, while uninstalling ATL71, the shared library atl71.dll is removed if its sharing reference count reaches 0. As a result, Microsoft SQL Server functionality might break.
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:
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 backups and restores of Windows 7 and Windows 2008 R2 x64 guest operating systems. However, file level backups are not supported with Windows 7 or Windows 2008 R2 x64 guests.
-
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.
- Resubscribe the CIM indications
You might not be able to employ this workaround. Sometimes resubscribing the CIM indications is not an option.
- Copy the appropriate files from the backup repository to the new repository as described in the substeps that follow.
This workaround recovers the CIM XML indication subscriptions.
- Move the following files from the back up repsoitory 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
- Restart the sfcbd-watchdog process.
Guest Operating System
-
Solaris 10 U4 virtual machine becomes nonresponsive 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 nonresponsive 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 autoconfiguration 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 WindowsNT guests 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.
-
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.
Workaround: Either of the following actions are appropriate as a workaround for this issue:
- Play video in full screen mode (ALT + ENTER).
- Uncheck Fit Video to player on resize.
-
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 could cause the virtual machine to crash.
-
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.
Internationalization
Licensing
Miscellaneous
-
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
-
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:
- Add a secondary service console.
- Change the gateway device of the service console.
- Change the gateway device back to primary service console.
- Remove the secondary service console.
Workaround: None
-
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 portgroup 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 portgroup. If multiple statically assigned VMKNICs are desired on the same vDS portgroup, then assign each VMKNIC or VSWIF to a unique set of services (for example, vMotion, Fault Tolerance, and other services).
-
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:
- Enter the Technical Support Mode.
- Restart slpd by running the /etc/init.d/slpd restart command.
- 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 is 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.
- On the vSphere Client Home page, click Host Profiles.
- Select the host profile in the inventory list, then click the Summary tab and click Edit Profile.
- Select Network configuration > Physical NIC configuration > Edit.
- Select Fixed physical NIC configuration in the drop-down menu and enter the speed and duplex information.
Storage
-
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.
-
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:
- Make sure the host does not use the LUN.
- Mask the LUN from the host.
- From the vSphere Client, rescan the storage adapter that the host uses to access the LUN.
- Unmask the LUN to make it accessible to the host.
- Rescan the storage adapter.
The service console now displays the correct size of the LUN.
-
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/
-
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.
-
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.
-
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
-
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
-
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.
-
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.
Upgrade and Installation
-
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.
-
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
deviceprobe
firewall --enabled
firewall --disabled (replaced by firewall --allowIncoming and 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
xdisplay
Workaround: Use only the kickstart commands supported by VMware. For a detailed list of supported commands, see the ESX and vCenter Server Installation Guide.
-
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 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.
-
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.
-
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.
-
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.
-
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
-
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 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.
-
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 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:
- Wait for the tasks to run at their scheduled
Next run time before upgrading.
- 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.
-
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.
-
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 1, 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 1 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 preconfigured 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 preconfigured 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 preconfigured 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
-
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
-
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
-
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.
-
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.
-
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:
- Select Start>Setting>Control Panel>User Accounts to open the User Accounts dialog box.
- Click Turn User Account control on or off.
- Deselect User Account Control (UAC) to help protect your computer and click OK.
- Reboot the machine when prompted.
Start the Linked Mode configuration process as follows:
- Select Start > All Programs > VMware > vCenter Server Linked Mode Configuration.
- Click Next.
- Select Modify Linked-Mode configuration and click Next.
- Click Join this vCenter Server instance to an existing Linked-Mode group or another instance and click Next.
- Enter the server name and LDAP port information and click Next.
- Click Continue to complete the installation.
- 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:
- Select Start > Setting > Control Panel > User Accounts to open the User Accounts dialog box.
- Click Turn User Account control on or off.
- Select User Account Control (UAC) to help protect your computer and click OK.
- Reboot the machine when prompted.
-
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:
- From a command prompt with administrator-level privileges, change directories to the vCenter Server installation directory.
- Delete the
VMwareVCMSDS directory.
- Recover the local LDAP instance by typing
jointool.bat recover.
-
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.
-
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
-
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
-
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:
- Log in to the vSphere Client on the host.
- Display the virtual machine clone in the inventory.
- Right-click the virtual machine and choose Delete from Disk.
- 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 iteself 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.
-
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 of NFS volume may be overriden 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.
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.
-
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
-
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.
Top of Page
|