VMware vSphere 4.1 Release Notes—ESXi Edition
ESXi 4.1 Installable | 13 Jul 2010 | Build 260247
ESXi 4.1 Embedded | 13 Jul 2010 | Build 260247
vCenter Server 4.1 | 13 Jul 2010 | Build 259021
Last updated: 18 Jul 2011
Check for additions and updates to these release notes.
What's in the Release Notes
The release notes cover the following topics:
VMware vSphere™ 4.1 includes VMware ESXi™ 4.1 Installable, VMware ESXi™ 4.1 Embedded, and VMware vCenter Server™ 4.1. Read about the new and enhanced features in this release in What's New in VMware vSphere 4.1.
VMware vSphere 4.1 is available in the following languages:
- Simplified Chinese
vSphere Client Locale Forcing Mode
With vSphere 4.1, you can configure the VMware vSphere Client™ to provide the interface text in English even when the machine on which it is running is not English. You can set this configuration for the duration of a single session by supplying a command-line switch. This configuration applies to the interface text and does not affect other locale-related settings such as date and time or numeric formatting.
The following vSphere Client command causes the individual session to appear in English:
vpxClient -locale en_US
Compatibility and Installation
ESXi, vCenter Server, and vSphere Client Version Compatibility
The vSphere Compatibility Matrixes provide details about the compatibility of current and previous versions of VMware vSphere components, including ESXi, vCenter Server, the vSphere Client, and optional VMware products. In addition, check the vSphere 4.1 Compatibility Matrixes for information about supported management and backup agents before installing ESXi or vCenter Server.
Hardware Compatibility for ESXi
To determine which processors, storage devices, SAN arrays, and I/O devices are compatible
with vSphere 4.1, use the ESXi 4.1 information in the
Hardware Compatibility Guide.
vSphere Client Connections to Linked Mode Environments with vCenter Server 4.1
vCenter Server 4.1 can exist in Linked Mode with other instances of vCenter Server 4.1 or vCenter Server 4.0 and later. If the vSphere Client that corresponds to the version of vCenter Server that you are trying to connect to is not installed on your system, you are prompted to download and install that version of the vSphere Client. After both versions of the vSphere Client are installed, you can access vCenter Server linked objects with either client. For Linked Mode environments with vCenter Server 4.0 and vCenter Server 4.1, you must have vSphere Client 4.0 Update 1 and vSphere Client 4.1. To download vSphere Client 4.0 Update 1, go to Download VMWare vSphere 4.
vSphere 4.1 and VMware View Compatibility
To learn about vSphere configurations supported with VMware View 4.0.x, see the Product Support Center for VMware View.
Installation Notes for This Release
Read the ESXi Installable and vCenter Server Setup Guide for step-by-step guidance on installing and configuring ESXi Installable and vCenter Server or the ESXi Embedded and vCenter Server Setup Guide for step-by-step guidance on setting up ESXi Embedded and vCenter Server.
After successful installation of ESXi Installable or successful boot of ESXi Embedded, several configuration steps are essential. In particular, some licensing, networking, and security configuration is necessary. For guidance on these configuration tasks, see the following guides in the vSphere documentation.
vCenter Server 4.1 supports installation on Windows 64-bit platforms only. If you have VMware 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.
Future releases of VMware vSphere might not support VMFS version 2 (VMFS2). VMware recommends upgrading or migrating to VMFS version 3 or later. See the vSphere Upgrade Guide.
vCenter Server 4.1 includes Management Information Base (MIB) files related to vCenter Server. You can download MIB files related to ESXi from the VMware Web site at http://www.vmware.com/download/vsphere/drivers_tools.html.
Upgrades for This Release
vCenter Server Upgrades
vCenter Server 4.1 must be installed on a 64-bit system. You can upgrade from vCenter Server 4.0 to vCenter Server 4.1 on the same system if it is 64 bit. To upgrade, first confirm that your database is supported with vCenter Server 4.1, and back up your supported database, SSL certificates, and vCenter Server configuration. Then run the vCenter Server installer. The installer informs you that an earlier version of vCenter Server is on the computer and will be upgraded.
You can also upgrade from VirtualCenter Server 2.5 or vCenter Server 4.0 on 32-bit systems to vCenter Server 4.1
on a 64-bit system by installing vCenter Server 4.1 on a 64-bit system and keeping the database from the VirtualCenter Server 2.5 or vCenter Server 4.0 system. You can use the data migration tool to migrate the vCenter Server configuration from the 32-bit system to the 64-bit system.
See the vSphere Upgrade Guide.
vSphere 4.1 offers the following tools for upgrading ESXi hosts:
If you have ESXi 3.5 and do not have vCenter Update Manager 4.1, you must upgrade to ESXi 4.0 or an ESXi 4.0 Update release by using vSphere Host Update Utility 4.0 or vCenter Update Manager 4.0. You can then upgrade to ESXi 4.1 by using vCenter Update Manager 4.1 or the vihostupdate utility. For detailed instructions, see the vSphere Upgrade Guide.
Test Releases of vSphere 4.1
Upgrades from the vSphere 4.1 Beta and the vSphere 4.1 Release Candidate releases to vSphere 4.1 are not supported. Uninstall ESXi 4.1 Beta or Release Candidate and vCenter Server 4.1 Beta or Release Candidate, and perform fresh installations of vCenter Server 4.1 and ESXi 4.1. If you were testing Beta or Release Candidate versions of vSphere 4.1, VMware recommends recreating data you want to preserve from those setups on vSphere 4.1.
Migration of virtual machines by using vMotion from a Beta or a Release Candidate host to a vSphere 4.1 host is not supported.
VMware vSphere SDKs
VMware vSphere provides SDKs for Web Services and guest operating systems:
vSphere Web Services SDK. This release of the vSphere Web Services SDK includes support for new features available in ESX 4.1 and vCenter Server 4.1 server systems. You can also use this SDK with previous versions of ESX and vCenter Server. For more information, see the VMware vSphere Web Services SDK Documentation.
vSphere Guest SDK. The VMware vSphere Guest SDK 4.0 is supported on ESX 4.1. For more information, see the VMware vSphere Guest SDK Documentation.
Open Source Components for vSphere
Open source components and their respective licenses for the most recent generally available release of vSphere is available at http://www.vmware.com/download/vsphere/open_source.html, under the Open Source tab. You can also download the source files for any GPL or LGPL, or other similar licenses that require the source code or modifications to source code to be made available, for the most recent generally available release of vSphere, by clicking on that link.
vSphere 4.1 Product, Feature, and Platform Support Notices
VMware vSphere 4.1 is the last release for the following product, features, and platforms. VMware will continue to provide technical support for these features and platforms through the end of their support lifecycles.
VMware ESX. VMware vSphere 4.1 and its subsequent update and patch releases are the last releases to include both ESX and ESXi hypervisor architectures. Future major releases of VMware vSphere will include only the VMware ESXi architecture.
- VMware recommends that customers start transitioning to the ESXi architecture when deploying VMware vSphere 4.1.
- VMware will continue to provide technical support for VMware ESX according to the VMware vSphere support policy on the
VMware Enterprise Infrastructure Support page.
- To learn more about the ESXi architecture and how to migrate from ESX to ESXi, go to the
VMware ESX to ESXi Upgrade Center.
VMware vCenter Converter plug-in. VMware vSphere 4.1 and its subsequent update and patch releases are the last releases for the VMware vCenter Converter plug-in for vSphere Client. VMware will continue to update and support the free Converter Standalone product, which enables conversions from sources such as physical machines, VMware and Microsoft virtual machine formats, and certain third-party disk image formats.
- VMware vCenter Guided Consolidation. VMware vSphere 4.1 and its subsequent update and patch releases are the last major releases for VMware Guided Consolidation. Customers who want to consolidate their physical servers have the following VMware vSphere service options:
- VMware vSphere with P2V Migration Jumpstart
- VMware Virtualization Assessment
- VMware P2V Accelerator Services
VMware vCenter Update Manager Features. vCenter Update Manager 4.1 and its subesquent update releases are the last releases to support scanning and remediation of patches for Windows and Linux guest operating systems and applications running inside a virtual machine. The ability to perform virtual machine operations such as upgrade of VMware Tools and virtual machine hardware will continue to be supported and enhanced.
VMware Consolidated Backup. VMware has extended the end of availability timeline for VCB and added VCB support for vSphere 4.1. VMware will continue to support VCB 1.5 Update 2 for vSphere 4.1 and its subsequent update and patch releases through the end of their lifecycles. Support is extended in accordance with the VMware support policy for the VMware Infrastructure 3 platform. New major or minor versions of the vSphere platform beyond vSphere 4.1 will not be supported with VCB.
VMI Paravirtualized Guest operating system support. vSphere 4.1 is the last release to support the VMI guest operating system paravirtualization interface. For information about migrating virtual machines that are enabled for VMI so that they can run on future vSphere releases, see Knowledge Base article 1013842.
vSphere Web Access. vSphere 4.1 is the last product release for vSphere Web Access. As a best practice, VMware recommends that you use the vSphere Client, which contains all the functionality of Web Access. Because vSphere Web Access is no longer being developed, support for this product is provided on a best effort basis.
Linux Guest Operating System Customization. vSphere 4.1 is the last release to support customization for the following Linux guest operating systems:
- RedHat Enterprise Linux (AS/ES) 2.1
- RedHat Desktop 3
- RedHat Enterprise Linux (AS/ES) 3.0
- SUSE Linux Enterprise Server 8
- Ubuntu 8.04
- Ubuntu 8.10
- Debian 4.0
- Debian 5.0
VMware will continue to deliver customization for newer versions of Linux guest operating systems from the RedHat Enterprise Linux and SUSE Linux Enterprise Server families.
Microsoft Windows 2000 MSCS. MSCS with Windows 2000 is not supported in vSphere 4.1. See the Microsoft Website for additional information.
For the VMware support policy for the vSphere platform, see the VMware Enterprise Infrastructure Support page.
The Known Issues section covers Functionality Caveats and provides a List of Known Issues.
IPv6 Disabled by Default. IPv6 is disabled by default when installing ESXi 4.1.
Hardware iSCSI. Broadcom Hardware iSCSI does not support Jumbo Frames or IPv6. Dependent hardware iSCSI does not support iSCSI access to the same LUN when a host uses dependent and independent hardware iSCSI adapters simultaneously.
List of Known Issues
The following known issues have been discovered through rigorous testing and will help you understand some behavior you might encounter in this release. This list of issues pertains to this release of vSphere 4.1 only. Some known issues from previous releases might also apply to this release. If you encounter an issue that is not listed in this known issues list, you can review the known issues from previous releases, search the VMware Knowledge Base, or let us know by providing feedback.
Features and known issues from previous releases of vSphere 4.0, which include ESX/ESXi 4.0 and vCenter Server 4.0, are described in the release notes for that release. To view the release notes for Sphere 4.0 and its subsequent update releases, see the VMware vSphere 4.0 Documentation page.
The known issues are grouped as follows:
DNS server settings are lost after second ESXi reboot
After ESXi is installed using the scripted installation method, the DNS server settings are lost when ESXi reboots for the second time. The settings are correct after the initial reboot following the installation but are lost after the second reboot.
/etc/resolv.conf using the
%firstboot kickstart command when you run the scripted installation of ESXi. This method might be preferable if you have a lot of hosts. Alternatively, you can reset the DNS through the direct console user interface for each ESXi instance.
Installation fails when you uninstall and reinstall vCenter Server
Installation fails with the error
Cannot create vCenter Server Directory Services when you uninstall and reinstall vCenter Server on the same system.
Workaround: After you uninstall vCenter Server, reboot the system before you reinstall vCenter Server.
When you uninstall vCenter Server 4.1 without stopping the vCenter Server service, the local ADAM instance might not be removed
You must stop the vCenter Server service before you uninstall vCenter Server 4.1 or the ADAM instance might remain on the system. This applies to both vCenter Server 4.1 installations and upgrades, and to stand-alone or linked vCenter Server systems.
Workaround: Stop the service VMware VirtualCenter Server before you uninstall vCenter Server 4.1.
vCenter Server instances that use a DB2 v9.5.0 database do not allow you to add a host
If you are using a vCenter Server system with an IBM DB2 v9.5.0 64-bit ODBC driver, you cannot manage hosts for that vCenter Server.
Workaround: Apply DB2 9.5 Fix Pack 5.
vCenter Server installation or upgrade silently changes Microsoft SQL Server settings to enable named pipes
When you install vCenter Server 4.1 or upgrade vCenter Server 4.0.x to vCenter Server 4.1 on a host that uses Microsoft SQL Server with a setting of "Using TCP/IP only," the installer changes that setting to "Using TCP/IP and named pipes" and does not present a notification of the change.
Workaround: The change in setting to "Using TCP/IP and named pipes" does not interfere with the correct operation of vCenter Server. However, you can use the following steps to restore the setting to the default of "Using TCP/IP only."
- Select Start > Programs > Microsoft SQL Server 2005 > Configuration Tools > SQL Server Surface Area Configuration.
- Select Surface Area Configuration for Services and Connections.
- Under the SQL Server instance you are using for vCenter Server, select Remote Connections.
- Change the option under Local and Remote Connections and click Apply.
vCenter Server installation fails with the error, Setup cannot create vCenter Directory Services instance
If the Everyone permission is removed from the HKLM registry, vCenter Server installation fails with the error,
Setup cannot create vCenter Directory Services instance.
Workaround: Add the Everyone permission to the HKLM registry:
- From the Windows command line, type
- In the Registry Editor, right-click HKEY_LOCAL_MACHINE and select Permissions.
- Click Add.
- Click Advanced.
- Select Everyone from the list and click OK.
- Click Apply and click OK.
Installation of the vSphere Client might fail with the error, The Microsoft Visual J# 2.0 Second Edition installer returned error code '4113'
When you install the vSphere Client, the installer might attempt to upgrade an out-of-date Microsoft Visual J# runtime. The upgrade will be unsuccessful and the vSphere Client installation fails.
Workaround: Uninstall all previous versions of Microsoft Visual J# and install the vSphere Client. The installation includes an updated Microsoft Visual J# package.
Installation of vCenter Server 4.1 using an existing IBM DB2 database sometimes fails with a DB2 error message
When you install vCenter Server 4.1 using an existing vCenter Server DB2 database, you might receive an error message similar to the following:
A database error occurred: "ODBC error: (5UA01) - [IBM][CLI Driver][DB2/NT64] SQL20453N The task "RULE_TOPN1_DB2USER1" cannot be removed because it is currently executing. SQLSTATE=5UA01" is returned when executing SQL statement "CALL CREATE_TOPN_JOB1_PROC()"
This message appears when DB2 encounters an IBM known issue. It indicates that a DB2 task is running and the vCenter Server installer cannot initialize the vCenter database.
Workaround: To eliminate the conflict so you can install vCenter Server, take the following steps:
- If vCenter Server is running, shut it down gracefully.
- Use the Services control panel to stop and restart the db2 service.
- Restart the installation process, being sure to select the option to overwrite the existing database.
vCenter Server installation fails if the user account used to install vCenter Server and overwrite an existing DB2 database is not member of the db2user group or the db2admin group
Error 25003: Cannot create repository is displayed when the user account used to install vCenter Server and overwrite an existing DB2 database is not a member of the db2user group or the db2admin group. Clicking OK in the error message dialog box closes the dialog box and rolls back the installation.
Workaround: Add the database user into db2user or db2admin group. Consult your database administrator.
After you install or upgrade to vCenter Server 4.1 with an Oracle database using an Oracle 64-bit ODBC driver, vCenter Server might fail to start
When you perform a new installation or upgrade to vCenter Server 4.1 with an Oracle database using an Oracle 64-bit ODBC driver, you might receive the error message,
Database version id '0' is incompatible with this release of VirtualCenter, and the vCenter Server service will fail to start.
Workaround: Upgrade to the 10.2.0.4 or 11.1 Oracle 64-bit ODBC driver.
vCenter Server upgrade proceeds despite changing Web Services HTTP or HTTPS port using established port
When changing the Web Services HTTP or HTTPS port by using an established port on the Configure Ports page, the vCenter Server upgrade proceeds and does not produce an error.
When you upgrade an ESXi 4.0 host to ESXi 4.1, then roll the host back to ESXi 4.0, the ESXi 4.1 versions of VMware Tools and the vSphere Client remain on the host
When you upgrade a host from ESXi 4.0 to ESXi 4.1, VMware Tools and the vSphere Client for ESXi 4.0 are removed and replaced with the ESXi 4.1 version of these components. If you roll the host back to ESXi 4.0, the ESXi 4.0 versions of VMware Tools and the vSphere Client are not restored.
For ESXi Embedded:
- Back up the ESXi configuration using the
- Reimage the USB key with a clean copy of ESXi 4.0.
- Restore the configuration using the
- Reregister the virtual machines.
For ESXi Installable:
- Back up the ESXi configuration using the
- Back up the VMFS datastores.
- Reinstall ESXi 4.0.
- Restore the configuration using the
- Restore the VMFS datastores.
- Reregister the virtual machines.
When you reboot an ESXi host after a successful upgrade to version 4.1, an error message appears
When you reboot the ESXi host after a successful upgrade performed by the vihostupdate utility, the following error message might appear:
New upgrade image appears corrupted, upgrade may fail.
This happens only when you upgrade from the ESXi versions 4.0 or 4.0 U1 to the 4.1 version. This does not apply to upgrades from 4.0 U2.
Workaround: You can ignore this error message and continue with the reboot. The upgrade will be successful.
Virtual machine MAC address conflicts
Each vCenter Server system has a vCenter Server instance ID. This ID is a number between 0 and 63 that is randomly generated at installation time but can be reconfigured after installation.
vCenter Server uses the vCenter instance ID to generate MAC addresses and UUIDs for virtual machines. If two vCenter Server systems have the same vCenter instance ID, they might generate identical MAC addresses for virtual machines. This can cause conflicts if the virtual machines are on the same network, leading to packet loss and other problems.
Workaround: If you deploy virtual machines from multiple vCenter Server systems to the same network, you must ensure that these vCenter Server systems have unique instance IDs.
To view or change the vCenter Server instance ID:
- Log in to vCenter Server using the vSphere Client, and select Administration > vCenter Server Settings.
- Select Runtime Settings.
The vCenter Server Unique ID text box displays the current vCenter Server instance ID.
- If this ID is not unique, enter a new value between 0 and 63 in the vCenter Unique ID text box and click OK.
- If you changed the vCenter Server instance ID, you must restart vCenter Server for the change to take effect.
If you have existing virtual machines with conflicting MAC addresses, edit the MAC addresses to make them unique:
- Ensure that the virtual machine is powered off.
- In the vSphere Client inventory, right-click the virtual machine and select Edit Settings.
- On the Hardware tab, select the virtual network adapter for the virtual machine.
- Under MAC Address, select Manual and enter a unique MAC address.
- Click OK.
Alternatively, you can force vCenter Server to generate a new MAC address for the virtual network adapter by configuring the virtual network adapter to use a Manual MAC address, and then reconfiguring it to Automatic.
Adding multiple hosts to a Cisco Nexus 1000v switch in one batch might fail
If you try to add multiple hosts with different patch or update levels to a Cisco Nexus 1000v switch, the add hosts operation fails.
Workaround: Add hosts with different patch or update levels to the switch individually.
Virtual machines lose network connectivity after hot adding or removing a vmxnet3 NIC with Wake-On-LAN enabled
Reconfiguring a vmxnet3 NIC while Wake-on-LAN is enabled and the virtual machine is asleep causes the device to malfunction, resulting in a loss of network connectivity for that NIC.
Workaround: Make configuration changes to a vmxnet3 NIC only when the virtual machine is awake.
Network connectivity failure and system crash while performing control operations on physical NICs
In some cases, when multiple X-Frame II s2io NICs are sharing the same pci-x bus, performing control operations, such as changing the MTU, on the physical NIC causes a loss of network connectivity and a system crash.
Workaround: Avoid having multiple X-Frame II s2io NICs in slots that share the same pci-x bus. In situations where such a configuration is necessary, avoid performing control operations on the physical NICs while virtual machines are doing network I/O.
Memory problems occur when a host uses more than 1016 dvPorts on a vDS
The maximum number of allowed dvPorts per host on vDS is 4096, but memory problems can start occurring when the number of dvPorts for a host approaches 1600. When this occurs, you cannot add virtual machines or virtual adapters to the vDS.
Workaround: Configure a maximum of 1016 dvPorts per host on a vDS.
Clone operation fails on a virtual machine with invalid vDS backing
If any of a virtual machine's network adapters is connected to an invalid or missing vDS or dvPort group, that virtual machine cannot be cloned.
Workaround: Make sure that all of a virtual machine's network adapters have valid backing before cloning the virtual machine.
Newly added users with read-only role can add VMkernel NICs to ESX/ESXi hosts
Newly added users with a read-only role cannot make changes to the ESX/ESXi host setup with the exception of adding VMkernel NICs, which is currently possible.
Workaround: None. Do not rely on this behavior because read-only users will not be able to add VMkernel NICs in the future.
Destroy operation fails on virtual machines with invalid vDS backing
If any of a virtual machine's devices is connected to an invalid vDS, a destroy operation might not complete successfully. The virtual machine is destroyed on the host, but remains in the vSphere Client inventory.
Workaround: To remove the virtual machine from the vCenter inventory, right-click the virtual machine and select Remove from inventory.
Poor TCP performance can occur in traffic-forwarding virtual machines with LRO enabled
Some Linux modules cannot handle LRO-generated packets. As a result, having LRO enabled on a VMXNET 2 or VMXNET 3 device in a traffic forwarding virtual machine running a Linux guest operating system can cause poor TCP performance. LRO is enabled by default on these devices.
Workaround: In traffic-forwarding virtual machines running Linux guests, set the module load time parameter for the VMXNET 2 or VMXNET 3 Linux driver to include
Server Configuration Issues
Virtual machines might become read-only when run on an iSCSI datastore deployed on EqualLogic storage
Virtual machines might become read-only if you use an EqualLogic array with an older firmware version. The firmware might occasionally drop I/O from the array queue, causing virtual machines to mark the I/O as failed and to turn to read-only.
Workaround: Upgrade EqualLogic Array Firmware to version 4.1.4 or later.
After storage array upgrade, the hardware acceleration status in the vSphere Client changes to supported after a short delay
When you upgrade a storage array's firmware to a version that supports VAAI functionality, vSphere 4.1 does not immediately register the change. The vSphere Client temporarily displays Unknown as the status for Hardware Acceleration.
Workaround: This delay is harmless. The hardware acceleration status changes to Supported after a short period of time.
Large number of storage-related messages in the vmkernel log file
When ESX or ESXi starts on a host with several physical paths to storage devices, the vmkernel log file records a large number of storage-related messages similar to the following:
Nov 3 23:10:19 vmkernel: 0:00:00:44.917 cpu2:4347)Vob: ImplContextAddList:1222: Vob add (@&!*@*@(vob.scsi.scsipath.add)Add path: %s) failed: VOB context overflow
The system might log similar messages during storage rescans. The messages are expected behavior and do not indicate any failure. They are harmless and you can safely ignore them.
Workaround: Turn off logging if you do not want to see the messages.
Persistent reservations conflicts on shared LUNs might cause ESX and ESXi hosts to boot longer
You might experience significant delays while booting your hosts that share LUNs on a SAN. This could be because conflicts between the LUN SCSI reservations.
Workaround: To resolve this issue and speed up the boot process, change the timeout for synchronous commands during boot time by setting the
Scsi.CRTimeoutDuringBoot parameter to 1.
To modify the parameter from the vSphere Client:
- In the vSphere Client inventory panel, select the host, click the Configuration tab, and click Advanced Settings under Software.
- Select SCSI.
- Change the
Scsi.CRTimeoutDuringBoot value to 1.
Also, see KB 1016106 at http://kb.vmware.com/kb/1016106.
vCenter Server and vSphere Client Issues
Applying profiles and checking profile compliance fails for host profiles after updating PnicsByName policy within DvsProfile
After updating the PnicsByName policy of DvsProfile, the host profile application and compliance check fails. This failure occurs when multiple physical NICs are entered. While the user interface allows multiple physical NICs, only one physical NIC can be added for the PnicsByName policy within DvsProfile.
Workaround: Ensure that only one physical NIC is added for this policy.
Performance data older than one day is not available for some entities when vCenter Server is configured to use DB2
Performance data older than one day is not available for some entities when vCenter Server is configured to use DB2.
NOTE: The UTIL_HEAP_SZ parameter allocates memory. This parameter can be tuned to increase memory allocation to DB2. Reduce diaglevel to 3 to reduce diag.log size and excessive log generation. This allows DB2 to process jobs in the background. Refer to http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/c0005389.htm for DB2 specific parameters.
Workaround: If you are using DB2 9.5, upgrade to DB2 9.5 Fix Pack 5.
Hot-plug operations fail after the swapfile is relocated
Hot-plug operations will fail for powered-on virtual machines in a DRS cluster, or on a standalone host, with an error
failed to resume destination; VM not found after the swap file location is changed.
Workaround: Do one of the following:
- Reboot the affected virtual machines to register the new swap file location with them, then perform the hot-plug operations.
- Migrate the affected virtual machines using vMotion.
- Suspend the affected virtual machines.
Accented and composite characters are not displayed in the index of French-language online Help
Accented and composite characters, such as Æ and Œ are not displayed in the indexes of French-language versions of the vSphere Client online Help, DRS Troubleshooting online Help, Overview Performance Charts Help, and Web Access online Help.
In Windows Vista, all Help buttons in the Update Manager Client open the default Update Manager help page
If you are using Internet Explorer 7 browsers installed on Windows Vista machines, the vCenter Update Manager context-sensitive help does not display the required help pages. Instead, the help displays the Introducing Update Manager help page.
Workaround: Apply Service Pack 2 to Windows Vista. For more details, see the following Microsoft knowledge base article http://support.microsoft.com/kb/942172.
Error loading performance chart data when vCenter Server uses a custom SQL Server database configured with a custom JDBC port
If a custom SQL Server instance is installed with vCenter Server and configured to use a custom JDBC port, the system displays the error
Perf Charts service experienced an internal error instead of chart data.
- On the vCenter Server system, navigate to
C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter.
- Open the
- Comment out the string
usevcdb = true.
- Ensure that the values for url, driver, and dbtype are as follows:
url = jdbc:sqlserver://:;integratedSecurity=true
driver = com.microsoft.sqlserver.jdbc.SQLServerDriver
dbtype = mssql
- Set the
integratedSecurity parameter to
true if the database resides on the local machine, or to
false if the database is remote.
- Restart the VMware VirtualCenter Management WebServices service.
NOTE: This problem does not occur with Oracle or DB2 databases that are configured with custom JDBC ports.
Datastore performance chart shows incorrect data
If you open the Performance tab from the the vSphere Client Datastore inventory view, the tab shows four graphs. The titles of these graphs are not correct and should read as follows:
- Max Latency per Host
- Max Queue Depth per Host
- Number of Reads per Host
- Number of Writes per Host
In some cases the plots might not show all the hosts, which is a known problem.
Workaround: To view the correct information for each host associated with a datastore, switch to the Host and Clusters inventory view, select the Performance tab, and look at the corresponding counter.
Problems installing or running vCenter Server, VMware Update Manager, or VMware Converter on an operating system using the Czech locale
If you attempt to install vCenter Server, Update Manager, or VMware Converter on an operating system using the Czech locale, you cannot install the product or experience functional problems when trying to use the product.
Workaround: No workaround for Czech locale operating systems. Use English locale operating systems to evaluate the product.
Failure when attempting to join a vCenter Server instance that is hosted on a system running Windows Server 2008 with User Account Control enabled with Linked Group
If you are joining or isolating a Windows Server 2008 system that has User Account Control (UAC) to a Linked Mode group, the operation fails without an error message.
Workaround: Perform the following steps:
- Turn off User Account Control (UAC) before joining a Linked Mode group as follows:
- Open the Windows Control Panel.
- Select Start > Setting > Control Panel > User Accounts.
- Click Turn User Account control on or off.
- Deselect User Account Control (UAC) to help protect your computer and click OK.
- Reboot the machine.
- Start the Linked Mode configuration as follows:
- Select Start > All Programs > VMware > vCenter Server Linked Mode Configuration and 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 Finish.
- Click Continue and follow the installation prompts.
- Log in to one of the vCenter Servers and verify that the servers are linked together.
- After the vCenter Servers are linked, turn on UAC.
- Select Start > Settings > Control Panel > User Accounts.
- Select Turn User Account control on or off.
- Select User Account Control (UAC) to help protect your computer and click OK.
- Reboot the machine.
Error occurs while trying to restart the VMware VirtualCenter service or the VMware Web service from Windows services panel
While you are trying to restart the VMware VirtualCenter service or the VMware Web service from the Windows control panel, you see the following message:
Error 1053: The service did not respond it the start or control request in a timely fashion.
Workaround: Modify two registry keys on the affected vCenter Server host as follows:
Launch regedit and locate the following key in the registry:
Add the following (DWORD) registry values:
Value: <Time to wait for service to start in milliseconds>
Value: <Time to wait for service to stop in milliseconds>
In both cases, the wait time should be greater than 40 seconds.
Locate the following key in the registry:
Add the following (DWORD) registry values:
Value: <Time to wait for service to start in milliseconds>
Value: <Time to wait for service to stop in milliseconds>
In both cases, the wait time should be greater than 40 seconds.
Changing the network settings of an ESXi host prevents some hardware health monitoring software from auto-discovering it
After the network settings of an ESXi host are changed, third-party management tool that relies on the CIM interface (typically hardware health monitoring tools) are unable to automatically and dynamically discover 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
sfcbd-watchdog using one of the following methods:
- Enter Technical Support Mode and run the following commands:
- Restart management agents on the Direct Console User Interface (DCUI). This will restart other agents on the host in addition to the agents affected by this defect and may be more disruptive.
When using DB2, the vCenter Server service does not restart automatically after network connectivity is restored
If you lose network connectivity to a vCenter Server system that is configured with an IBM DB2 database, you will be unable to start the vCenter Server service after network connectivity is restored.
- Close all existing connections from the vCenter Server machine to the IBM DB2 database using the Application List utility.
- Log in to the DB2 UDB database as dbadm, as the instance owner, or as the database owner.
- Run the following command to obtain information about the user you want to disconnect from the database:
db2 list applications
A message similiar to the following message appears:
Auth Id Application Appl. Application Id
-------- -------------- ---------- --------------------------
VPX db2bp.exe 3428 *LOCAL.DB2.100225221240
- Note the application handle number and use it to issue the following disconnect command:
force application <application_handle_number>
VMware HA and Fault Tolerance Issues
Migrating a powered-off or suspended ESX 3.x virtual machine with snapshots to another datastore might make the target virtual machine unusable
When you attempt to migrate a powered-off or suspended ESX 3.x virtual machine with snapshots to another datastore, you might see the following warning message:
This virtual machine has snapshots. Moving it to another datastore might make the virtual machine unusable. Search the VMware Knowledge Base for more information.
If you have completed the migration of the virtual machine, you might see the following error message when you attempt to power on the virtual machine:
File was not found
Workaround: See KB 1020709.
After a virtual machine is migrated, USB devices on the destination host might incorrectly show up as assigned to the virtual machine
After you migrate a virtual machine with host-connected USB devices and then add additional USB devices to the migrated virtual machine on the destination host, USB devices on the destination host might show up as assigned to the virtual machine even though they have not been assigned to it.
Workaround: Assign the USB devices to a local virtual machine that was not migrated from another host to prevent them from showing up as assigned to the migrated virtual machine. There is no workaround to allow these devices to be assigned to the migrated virtual machine.
Guest Operating System Issues
ESXi host may report VMware HA errors if rebooted within 10 minutes of HA configuration
A logic error exists in persisting the HA state. When the host reboots shortly after HA configuration has completed, it does not find the cluster configuration information and fails to start the HA agent.
Workaround: Wait more than 10 minutes before powering off the host after the HA configuration task is completed.
Supported Hardware Issues
Compiling VMware kernel modules is supported only for the running kernel
VMware currently supports compiling kernel modules only for the currently running kernel.
Workaround: Boot the kernel before compiling modules for that kernel.
RPM installer for VMware Tools for RHEL3, RHEL4, and SLES9 fails to verify the package signature
When you use the RPM Installer to install VMware Tools for RHEL3, RHEL4, and SLES9, signature verification fails with the message
V3 RSA/MD5 signature: NOKEY, key ID 66fd4949. This condition occurs because older versions of RPM cannot verify RSA signatures created by newer versions of RPM. Failure to verify the package signature does not prevent VMware Tools from installing successfully.
Workaround: Use RPM 4.4.2 or later to verify the packages.
Installation of VMware Tools Operating System Specific Packages (OSPs) on SUSE Linux 9 results in screen resolution error
When you install the VMware Tools OSP in SUSE Linux 9, the operating system configures the X Window System
/etc/X11/XF86Config file and replaces the vesa video driver with the VMware video driver. If you are using a video driver other than vesa, the VMware Tools OSP does not replace it. Attempts to change the screen resolution by using the GUI or the Linux
xrandr command fail.
Workaround: Edit the
/etc/X11/XF86Config file to use the VMware video driver.
- Log in to the X Window System
/etc/X11/XF86Config file as root.
- Locate the device section.
- Locate the Driver entry or create it if it does not exist.
- Set the Driver entry to vesa.
After the change, the driver appears in the device section as Driver vesa.
- Restart the X Window System to save the changes and apply the new settings.
Installing VMware Tools OSP packages on SLES 11 guest operating systems produces a "packages not supported" message
Installation of VMware Tools OSP packages in a SUSE Linux Enterprise Server 11 guest operating system produces the error message,
The following packages are not supported by their vendor.
Workaround: Ignore the message. The OSP packages do not contain a tag that marks them as supported by the vendor. However, the packages are supported.
Guest OS is unresponsive after hot-adding memory from less than 3GB to greater than 3GB
The Redhat5.4-64 guest operating system might become unresponsive if it is started with an IDE device attached, and memory is hot-added from less than 3GB to greater than 3GB.
Workaround: Do not use memory hot-add to change the virtual machine size from less than or equal to 3072MB to greater than 3072MB. Power off the virtual machine to perform this reconfiguration.
If the guest OS is already unresponsive, restart the virtual machine. This problem occurs only when the 3GB mark is crossed while the operating system is running.
Windows NT guest operating system installation error with hardware version 7 virtual machines
When you install Windows NT 3.51 in a virtual machine that has hardware version 7, the installation process freezes. This happens immediately after the blue startup screen with the Windows NT 3.51 version appears. This is a known issue in the Windows NT 3.51 kernel. Hardware version 7 virtual machines have over 34 PCI buses and the Windows NT kernel supports hosts that have a limit of 8 PCI buses.
Workaround: If this is a new installation, delete the existing virtual machine and create a new one. During virtual machine creation select hardware version 4. You must use the New Virtual Machine wizard to select a custom path to change the hardware version.
If you created the virtual machine with hardware version 4 and upgraded it to hardware version 7, use VMware vCenter Converter to downgrade the virtual machine to hardware version 4.
vSphere Command-Line Interface Issues
New: Installation or upgrade fails with a purple diagnostic screen on ESX/ESXi hosts equipped with HP NC522SFP network cards
On some ESX/ESXi hosts equipped with NC522SFP network cards, the inbox NetXen driver fails to load the firmware causing the host to fail with a purple diagnostic screen during the ESX/ESXi installation or upgrade process. The host displays a message similar to
Workaround: Perform one of the following procedures as appropriate:
ESX. When prompted for the driver during installation or upgrade, install the async driver provided on this page: VMware ESX/ESXi 4.0 Driver CD for QLogic Intelligent Ethernet Adapters. You should select driver version 507 or later.
ESXi Embedded. Contact your host vendor to obtain a custom system image that includes the correct driver.
ESXi Installable. ESXi Installable supports the NC522SFP card only if the host has at least one other network card of a different type. If your host meets this criterion, complete these steps:
- Deactivate the NC522SFP network card or remove it from the host.
- Install or upgrade ESXi Installable on the host.
- When installation or upgrade finishes, install the async driver provided on this page: VMware ESX/ESXi 4.0 Driver CD for QLogic Intelligent Ethernet Adapters. You should select driver version 507 or later.
- Reactivate or re-install the NC522SFP network card in the host.
If your ESXi Installable host does not have a network card other than an NC522SFP, there is no workaround.
Also, see KB 1026431.
PCI device mapping errors on 370 G6 HP server
When you run I/O operations on the 370 G6 HP server, you might encounter a purple screen or see alerts about 'Lint1 Interrupt' or NMI on the console. The HP ProLiant DL370 G6 server has two Intel I/O hub (IOH)s and a BIOS defect in the ACPI Direct Memory Access remapping (DMAR) structure definitions, which causes some PCI devices to be incorrectly described under the wrong DMA remapping unit. Any DMA access by such incorrectly described PCI devices trigger an IOMMU fault and the device will receive an I/O error. Depending on the device, this I/O error might result in an Lint1 Interrupt or NMI alert message on the console or the system might freeze with a purple screen.
Workaround: Check the HP Web site for availability of a BIOS patch for the HP ProLiant DL370 G6 server. If a patch is not available, disable 'Intel(R) VT-d' in the BIOS so that the BIOS will not publish DMAR structures in the ACPI tables.
ESXi installations on HP systems require the HP NMI driver
ESXi 4.1 instances on HP systems require the HP NMI driver to ensure proper handling of non-maskable interrupts (NMIs). The NMI driver ensures that NMIs are properly detected and logged. Without this driver, NMIs, which signal hardware faults, are ignored on HP systems with ESXi.
CAUTION: Failure to install this driver might result in silent data corruption.
Workaround: Download and install the NMI driver. The driver is available as an offline bundle from the HP Web site. Also, see KB 1021609.
Group ID length in vSphere Client shorter than group ID length in vCLI.
If you specify a group ID using the vSphere Client, only nine characters are allowed. In contrast, you can specify up to ten characters if you specify the group ID using the
Running resxtop for extended periods might result in memory problems
Memory usage by resxtop might increase over time depending on what happens on the ESX/ESXi system being monitored. Because resxtop also causes extra CPU consumption on ESXi, VMware recommends that you not leave resxtop running for a very long time, that is, for a few weeks.
The total number of iterations on ESXi 4.1 (-n) is set to a default value of 10,000. After resxtop has generated 10,000 displays, it shuts itself down. That means that if a default delay of 5 seconds between two displays is used, resxtop might shut itself down after around 14 hours.
Workaround: Although you can use the -n option to change the total number of iterations, it is better to run resxtop only when you need the data. If you do have to collect resxtop statistics over a long time, shut down and restart resxtop periodically instead of running one resxtop instance for weeks or months.
DVM/Host DRS Rules are still enforced if DRS is disabled
If you specified a VM/Hosts DRS rule for a DRS cluster, if DRS is disabled, this rule is still in effect. Accordingly, if you manually power on a virtual machine specified in this type of rule, an error might result if this operation violates the rule.
Workaround: Manually disable the rule in the cluster Settings dialog box.