VMware

VMware ESX Server 2.1.3 Release Notes

Build 22983 is the release build of VMware ESX Server 2.1.3.

Check back frequently for additions and updates to these release notes.

Last updated: 03/14/2006

What's in This Release Note

The release notes cover the following topics.

Last update to the release notes include the following new issues:

Linux Kernel Update for ESX Server 2.1.1
ESX Server 2.1.2 includes a patch for the following vulnerability:

OpenSSL Security Notification for ESX Server 2.1.2
ESX Server 2.1.2 includes OpenSSL version 0.9.6b, and is not affected by the following security vulnerabilities reported by the CERT® Coordination Center:
  • CAN-2004-0079: Null-pointer Assignment During SSL Handshake
    Description: The do_change_cipher_spec function in OpenSSL 0.9.6c to 0.9.6k, and 0.9.7a to 0.9.7c, allows remote attackers to cause a denial of service (crash) via a crafted SSL/TLS handshake that triggers a null dereference. For more details on this security vulnerability please refer to: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0079.

  • CAN-2004-0112: Out-of-bounds Read Affects Kerberos Ciphersuites
    Description: The SSL/TLS handshaking code in OpenSSL 0.9.7a, 0.9.7b, and 0.9.7c, when using Kerberos ciphersuites, does not properly check the length of Kerberos tickets during a handshake, which allows remote attackers to cause a denial of service (crash) via a crafted SSL/TLS handshake that causes an out-of-bounds read. For more details on this security vulnerability please refer to: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0112.

What's New in ESX Server 2.1.3 (Build 22983)

What's New in ESX Server 2.1.2 (Build 9638)

  • Expanded Support for Dell Servers
    ESX Server 2.1.2 includes support for the following Dell servers:
    • Dell PowerEdge 1850
    • Dell PowerEdge 2850
  • Support for Blade Servers
    ESX Server 2.1.2 includes support for the Intel® Server Compute Blade SBX44 server.
  • Support for Dell PercRAID Controllers
    ESX Server 2.1.2 includes support for the following RAID controllers:
    • PERC 4/SI
    • PERC 4/DI
  • Expanded Support for Opteron-based Systems
    ESX Server version 2.1.2 includes support for the following Opteron-based systems:
    • IBM eServer 325
    • HP ProLiant DL585

What's New in ESX Server 2.1.1 (Build 9157)

  • Expanded Support for Processors
    ESX Server version 2.1.1 includes support for the AMD Opteron processor.
  • Support for ProLiant ML570 G2 CD-ROM Drive
    ESX Server version 2.1.1 includes support for the ProLiant ML570 G2 CD-ROM drive.
  • Support for LSI 1020/1030 Controllers in Shared Mode with Mirrored Disks
    ESX Server version 2.1.1 supports using a LSI 1020/1030 SCSI controller in shared mode with mirrored disks.
  • Support for More Than 48GB of RAM in a Non-NUMA Server
    ESX Server version 2.1.1 supports using more than 48GB of memory on non-NUMA servers.

  • Support for Citrix MetaFrame
    For ESX Server 2.1, running Citrix MetaFrame in a Windows 2000 Server guest operating system may have caused the system to fail or show errors. This issue is resolved in ESX Server version 2.1.1.

What's New in ESX Server 2.1

  • Hyper-Threading Support
    Hyper-Threading support enables you to double the number of logical processors in your ESX Server, which can improve machine utilization and performance for multi-virtual machine workloads. For more information on Hyper-Threading technology, see http://www.intel.com/technology/hyperthread/.

    Note: ESX Server supports Hyper-threading for up to eight physical CPUs in the system.

    Note: To enable Hyper-Threading, you may need to modify BIOS settings on the machine where the ESX Server is installed. Depending on your machine, this option may be named "Enable Hyperthreading" or "Enable Logical Processors." Please refer to the documentation for your machine on how to enable Hyper-Threading, or contact the manufacturer of the machine for instructions.

  • New Graphical Installer
    ESX Server 2.1 includes a new graphical installer for new installations and upgrades from older server versions. The new installer includes the functionality of the ESX Server 2.0.1 text-based installer, and also new functionality like serial number entry, disk partition creation, and memory sizing. Once the installation is complete, only a single server reboot is necessary before new virtual machines can be created.
  • Enhanced Support for Scripted Installations
    Through the management interface, the scripted installation feature allows you to set up an installation script to deploy or provision more ESX Server systems, where the ESX Server CD-ROM is in the CD-ROM drive of the original ESX Server system or the installation files are hosted on a separate server.
  • Support for Virtual Local Area Networks
    Virtual Local Area Networks (VLANs) support enables you to configure multiple virtual networks within your ESX server, which communicate securely among themselves as if connected to a common isolated physical network. Virtual networks with VLAN support are able to manage traffic by switching VLAN traffic to and from virtual machines, including traffic external to the ESX Server. Virtual machine VLANs are configured through the management interface.
  • Redesigned Network Connections Management Through the Management Interface Through the management interface, you can review current external, VLAN, and internal network connections, create new networks and edit existing network configurations, and review network adapter status and edit existing adapter configurations.
  • ESX Server and Virtual Machine Memory Resources
    Through the management interface, you can view the memory utilization page, which shows how much memory is being used by the ESX Server and how memory resources are allocated to virtual machines.
  • Virtual Machine Startup and Shutdown Options through the VMware Management Interface
    Through the management interface, new configuration options for starting and shutting down virtual machines are available. You can determine which virtual machines start and stop with the system, set the delay time between starting and stopping one virtual machine and starting and stopping the next, and determine the global order in which virtual machines start and stop. Virtual machine configuration options can be set for each individual virtual machine or can be set system-wide.
  • Support for Preboot Execution Environment (PXE)
    Virtual machines created with VMware ESX Server 2.1 have built-in support for Preboot Execution Environment (PXE), using either the vlance or vmxnet virtual network devices. PXE allows a computer without an operating system installed to power on and download an operating system image from a PXE server on the network.

    Note: In this release you can only use vlance virtual adapters with either Remote Installation Service or Automatic Deployment Service PXE servers.

  • Expanded Support for SAN Storage Arrays
    ESX Server 2.1 includes failover support for EMC CLARiiON CX Series storage systems, including multipathing with HBA failover and multipathing with storage port failover. For information on supported SAN storage devices and configurations, download the VMware ESX Server Compatibility Guide at www.vmware.com/pdf/esx201_SAN_guide.pdf.
  • ESX Server Compatibility with VMware VirtualCenter
    Use the VMware VirtualCenter system management application to deploy, monitor, and manage virtual machines that are distributed across multiple hosts running ESX Server. For more information about VirtualCenter, see http://www.vmware.com/support/vc/.

Installation Notes for This Release

Management Agents

Known Issues with This Release

Installation

Configuration

Guest Operating System

Operation

Errata to the Release Documentation

Installation Notes for This Release

Installing ESX Server on IBM BladeCenter and HP Blade Servers
For information on using ESX Server with blade servers, see Configuring and Installing HP Blade Servers and Configuring and Installing IBM BladeCenter.

Installing the VMware Virtual SMP Product
If you have purchased the VMware Virtual SMP product, then you can create Symmetric Multiprocessing (SMP) virtual machines, with single or dual virtual CPUs. You install the Virtual SMP product during your ESX Server installation by inserting its serial number during the Licensing step of your ESX Server installation.

Upgrading a Previous ESX Server Release to ESX Server 2.1.3
ESX Server 2.1.3 supports upgrading from the following previous releases:

  • ESX Server 2.1.2
  • ESX Server 2.1.1
  • ESX Server 2.0.2 (to be released Q2 2006)
  • ESX Server 2.0.1 with Upgrade Patch 6
  • ESX Server 2.0.1

    Note: Upgrading directly from ESX Server 1.0 or 1.1 to ESX Server 2.1.3 is not supported.

To upgrade from previous versions of ESX Server to ESX Server 2.1.3, use the installation CD-ROM. This is the CD you received from VMware or the CD you created from the ISO image file you downloaded from the VMware site. For upgrade instructions, see Upgrading from ESX Server 1.5.2 or ESX Server 2.0.x.

Note: If you are upgrading from an ESX Server release prior to 1.5.2, then SNMP will not work properly. This is due to a change in ESX Server architecture. For more information, see Upgrading SNMP for a Previous ESX Server Release.

Note: During an upgrade from a previous ESX Server release to ESX Server 2.1.3, this upgrade installer reinstalls all default ESX Server RPMs. If you have modified any of the default ESX Server RPMs, these modifications will be overwritten during the upgrade.

Note: Previous versions of VMware ESX Server store obfuscated login credentials for the VMware Management Interface in the vmware.mui.kid cookie. Starting with ESX Server version 2.1.3, login credentials for the VMware Management Interface are stored elsewhere, and the vmware.mui.kid cookie is not used. To ensure that this cookie is removed, after upgrading, close all instances of the web browser used to log in to the VMware Management Interface. For more information, see Knowledge Base article 2073 at http://kb.vmware.com/kb/2073.

Upgrading from a Tar Archive
If you are using the downloaded tar archive, note the filename of the download file and make appropriate substitutions in the file and directory names shown below.

Note: Using the tar archive, upgrading directly from releases prior to ESX 2.0 is not supported.

  1. Reboot into linux.
    /sbin/lilo -R linux
    /sbin/reboot
  2. Log in as root.
  3. Make a directory named download (or use another name of your choice). This directory must be accessible to the service console on the server you want to upgrade.
  4. Save the file esx-2.1.3-22309-upgrade.tar.gz to this directory.
  5. Change to the download directory.
  6. Extract the contents of the file.
    tar zxf esx-2.1.3-22309-upgrade.tar.gz
  7. Change to the directory esx-2.1.2-9638-upgrade.
  8. Run the upgrade script.
    ./upgrade.pl
  9. You see various messages about the upgrade process.
  10. When prompted, reboot the system. When the system reboots, you are finished upgrading VMware ESX Server.

Upgrading Default Speed/Duplex Setting for NICs for a Previous ESX Server Release
The default speed/duplex setting for ESX Server NICs has changed from "100/1000/full" in ESX Server 1.5.2 to "autonegotiate" in ESX Server 2.1.2 and ESX Server 2.1.3.

Action:
If you are upgrading from ESX Server 1.5.2, then you may need to alter your switch's setting to "autonegotiate", for ports connected to the ESX Server machine, or you may force the NICs to full duplex in the NIC configuration page. (Log into the VMware Management Interface as the root user, click the Options tab, then click Network Connections.)

Note: It is important that both the switch port and the NIC are either both set to autonegotiate, or both forced to the same speed/duplex setting.

Upgrading SNMP from a Previous ESX Server Release

Action:
To upgrade SNMP from ESX Server 1.5.2, complete the following steps.

  1. Save and copy onto another machine the following files:
    • /etc/vmware/vmware-snmpd.conf— Save this file, but remove the last section that starts with "# VMware ESX Server SNMP modules -- Edit this section at your own risk". We'll call this file Alpha.
    • (Optional) /etc/snmp/snmpd.conf— If you have this file, and made changes to it or if you have installed third-party system management software on ESX Server, then save this file. We'll call this file Beta.
  2. If you've created only an Alphafile, then rename it to MAIN. If you've created Alphaand Beta, then merge your customizations into a single file, called MAIN. Be sure to eliminate any duplicate configuration items in the MAINfile.
  3. Follow the instructions in Upgrading from a Previous Version of ESX Server.
  4. Complete one of the following, depending on whether you are only using VMware ESX Server SNMP or if you are using VMware ESX Server SNMP with third-party system management agents:
    • Only using VMware ESX Server SNMP
      1. Take the MAIN file you created and rename it on ESX Server as /etc/snmp/snmpd.conf.
      2. Use the VMware Management Interface to configure the vmware-snmpd agent and restart SNMP services. See Configuring the ESX Server Agent through the VMware Management Interface.
    • Using VMware ESX Server SNMP with third-party system management agents
      1. Upgrade or reinstall your third-party system management agents. Refer to your management application documentation.
      2. Take the MAINfile you created and rename it on ESX Server as /etc/snmp/snmpd.conf.
      3. Use the VMware Management Interface to configure the vmware-snmpdagent and restart SNMP services. See Configuring the ESX Server Agent through the VMware Management Interface.
      4. Restart the third-party system management agents according to the vendor's procedures.

Upgrading if the VMware Idler Service is Installed on SMP-enabled Windows 2000 Virtual Machines
For this release, the VMware Idler Service is not needed. If upgrading to ESX Server 2.1.3 from previous versions, ESX Server 2.1.3 tools automatically remove the idler service from existing virtual machines.

Management Agents

Installing HP Insight 7.0 Management Agents on the Service Console
ESX Server 2.1.3 supports HP Insight Management Agents 7.0, and provides a script for installing them on the service console. For further information on installing HP Insight 7.0 Management Agents on the service console, see Configuring Management Agents for ESX Server 2.1.

Installing HP Insight Manager 6.4 Management Agents on the Service Console
ESX Server 2.1.3 supports HP Insight Management Agents 6.4. HP provides a script for installing them on the service console. For further information on installing HP Insight Manager 6.4 Management Agents on the service console, see Configuring Management Agents for ESX Server 2.1.

Installing Dell OpenManage 3.7 or 3.8 Management Agents on the Service Console
ESX Server 2.1.3 supports Dell OpenManage 3.7 or 3.8 Management Agents. For further information on installing Dell OpenManage 3.7 or 3.8 Management Agents on the service console, see Configuring Management Agents for ESX Server 2.1.

Installing IBM Director 4.12 Management Agents on the Service Console
ESX Server 2.1.3 supports IBM Director 4.12 Management Agents. For further information on installing IBM Director 4.12 Management Agents on the service console, see Configuring Management Agents for ESX Server 2.1.

Known Issues with This Release

Installation

2TB Disk Partition Creation Not Supported During ESX Server Installation
If you are installing ESX Server on a machine with an attached disk array that is 2TB or greater in size, you may receive and error message indicating that ESX Server is unable to initialize or read from the disk.

Action:
If this occurs, do not select the option to initialize the disk array during the installation. After ESX Server is installed, use the management interface to partition the disk. For instructions, See Configuring Storage: Disk Partitions and File Systems for more information.

Use the "Custom" Installation Option if using Non-US Keyboards
If you are using a non-US Keyboard, and installing or upgrading ESX Server using scripted and text-mode installations, choose the "Custom" installation method. This option allows you to choose your keyboard type during the installation. Choosing the "Default" installation option is not supported.

Scripted and Text-Mode Installations Server Configuration Steps
If using scripted and text-mode installations, some configuration options, such as PCI divvy and core and swap file creation, which are usually performed during the installation, must be done through the management interface.

No Default vmkernel Swap File Creation
The vmkernel swap file is not created or enabled by default during the installation. To create and configure a vmkernel swap file, use the management interface.

No Default vmcore Core Dump Partition Creation
The vmcore dump partition, used for vmkernel core dumps, is not created during the text-based installation or it is not the last partition on the disk using autopartition. To create and configure a vmcore dump partition, or set the vmcore as the last partition on the disk, use the management interface.

Booting into Linux with Hyper-Threading Enabled
If you have Hyper-Threading enabled, then you might see an incorrect message indicating that you have double the number of CPUs on your server. This only occurs when booting your ESX Server into Linux. You can safely disregard this incorrect information.

Upgrading from ESX Server 2.1.3 to ESX Server 2.5.x
In ESX Server 2.0.2, 2.1.3, and 2.5.3 releases, RPMS have been upgraded from the previous ESX Server versions. To avoid downgrading these RPMs to the older version, when you upgrade ESX Server 2.1.3 to ESX Server 2.5.x, you must upgrade only to ESX version 2.5.3 or later. For more information, see Knowledge Base article 2065 at http://kb.vmware.com/kb/2065.

Upgrading to Version 2.1.3 Creates Unnecessary File
Installing ESX Server 2.1.3, or upgrading to ESX Server 2.1.3 from a previous version, creates the unnecessary file perllocal.pod in the / directory. You can safely delete this file.

Configuration

MSCS Clustering on IBM Shark Storage Servers
This version of ESX Server does not support MSCS clustering on IBM Shark storage servers. VMware recommends that online maintenance not be performed on the IBM Enterprise Storage Server when attached to ESX Server 2.1.2 with MSCS clustered Windows virtual machines.

Configuring Virtual Machines with SCSI Reset Options
You can now adjust how ESX Server handles SCSI resets issued by a virtual machine. If the guest operating system resets a virtual adapter while it is accessing a virtual disk, the state of the adapter in the virtual machine can become unsynchronized with the state of the adapter recognized by ESX Server. This release includes two new configuration options for virtual machines, maxResetLoops and postResetDelay, that allow you to modify how ESX Server handles SCSI bus resets.

The scsi<n>.maxResetLoops option defines the number of times ESX Server will attempt to complete a SCSI reset for the virtual adapter numbered n. It has a default value of 2147483647. The scsi<n>.postResetDelay option defines the delay, in seconds, between reset attempts, with a default value of 30 seconds.

For details on how to set these options with the Management Interface, see Modifying the Configuration File Directly.

Using VLAN Tagging with Network Switches
If you use ESX Server to route VLAN network traffic, you may need to reconfigure switches attached to your system. Some switches define a "native" VLAN that is used by default. A native VLAN will be associated with a particular VLAN ID number. For instance, on a Cisco switch the ID of the native VLAN is 1, by default. Network traffic using the same ID number as a native VLAN may have the VLAN ID (802.1q) tags automatically removed when routed through the switch, depending on its configuration.

ESX Server requires these ID tags to route traffic in the two VLAN modes supported within the system:

  • Virtual switch routing with port groups (switch tagging)
  • Virtual machine routing (guest tagging)
Check the configuration of attached switches to ensure that default settings do not interfere with the VLAN modes you have chosen for your server. Switch ports connected to your system must be configured as trunk ports that will pass through traffic without removing VLAN ID tags.

You should avoid using a native VLAN when designing the configuration for your external and virtual switches. Using specific ID tags, rather than the default VLAN ID, may prevent networking failures if an external switch is returned to its default settings. Also, avoiding native VLANs provides a more secure interface between virtual machines and your network.

If you are already using a native VLAN, you can reconfigure your switch to pass through ID tags on all ports, including native traffic (that is, messages using the ID of the native VLAN). Set the switch to enable 802.1q tags for all VLAN ID values, either globally or for the trunk ports connected to your system. See the documentation for your switch for details.

The Service Console Fails to Connect to the Network
If the vmkernel fails to load and you see the error message "The service console is not correctly connected to the network," this means that the IP address for the service console needs to be manually configured.

Action:
The service console's hostname must not be on the same line where 127.0.0.1 is located in /etc/hosts. To resolve the problem, edit /etc/hosts, and move the local machine's external name to a new line beginning with its external IP address. For example, if the name of the machine is "finance" and its external IP address is 63.93.12.85, the resulting file will be similar to this:
127.0.0.1 localhost.localdomain localhost
63.93.12.85 finance.vmware.com finance

IEEE 802.3ad and the Cisco Fast Ether Channel/Gigabit Ether Channel Not Needed for NIC Teaming
ESX Server 2.1.2 no longer requires you to use the 802.3ad protocol with NIC teaming. You can disable 802.3ad on ethernet switches connected to ESX Server in most cases. Virtual switches configured to use NIC teaming with the IP Load Balancing mode, however, must still be connected to external switches using static 802.3ad.

Using DHCP with a Broadcom 5700/5701 Network Interface Cards
If you have ESX Server configured to use a Broadcom 5700/5701 as the network adapter dedicated to the service console, you may encounter delays on system startup if you have configured your server to poll a DHCP address server to acquire an IP address. If you encounter startup delays using this configuration, check the system log file /var/log/vmkernel. If the log file contains the error message "VMkernel ID derived from Loopback address," you should choose a static IP address to assign to your server.

Action:
If you must use DHCP, you can configure ESX Server to wait longer for the DHCP server to respond with an address. To do so, follow these steps:

  1. As root, log in to the service console.
  2. Search for the configuration file for the adapter using DHCP:
    # grep DHCP /etc/sysconfig/network-scripts/ifcfg-eth*

    In most cases this will be the file for eth0.

  3. Open the configuration file with the filename displayed by grep.
  4. Append the following configuration string to the end of the file:
    DHCPCDARGS="-t 125"
  5. Save and close the configuration file.

    You need to set DHCPCDARGS for each Broadcom adapter assigned to the service console that is using DHCP.

Using HP StorageWorks MSA 1000 with ESX Server
To use the HP StorageWorks MSA 1000 with ESX Server, the fibre channel connections between the SAN array and the ESX Server must be configured with the Profile Nameset to Linux.

Action:
To set the Profile Name for a connection, perform the following setup tasks.

  1. Create a static connection on the MSA 1000 using the MSA 1000 command line interface.

    Refer to HP's StorageWorks MSA 1000 documentation http://h18006.www1.hp.com/products/storageworks/msa1000/documentation.html to learn how to install and configure the command line interface.

    Note: Connection settings cannot be created using the HP Array Configuration Utility.

  2. Connect the MSA 1000 command line interface to the MSA 1000. Verify that the fibre channel network between the MSA 1000 and the ESX Server is working.
  3. Start the command line interface. At the prompt, enter:
    SHOW CONNECTIONS

    The output displays a connection specification for each FC WWNN/WWPN attached to the MSA 1000:
    Connection Name: <unknown>
    Host WWNN = 22222222-22222222
    Host WWPN = 33333333-33333333
    Profile Name = Default
    Unit Offset 0
    Controller 1 Port 1 Status = Online
    Controller 2 Port 1 Status = Online

    Make sure the Hosts WWNN and WWPN show the correct connection for each Fiber Channel Adapter on the ESX Server.

  4. Create a static connection:
    ADD CONNECTION ESX_CONN_1 WWNN=22222222-22222222 WWPN=33333333-33333333 PROFILE=LINUX
  5. Verify the connection:
    SHOW CONNECTIONS

    The output displays a single connection with the 22222222-22222222/33333333-33333333 WWNN/WWPN pair and its Profile Name set to Linux:
    Connection Name: ESX_CONN_1
    Host WWNN = 22222222-22222222
    Host WWPN = 33333333-33333333
    Profile Name = Linux
    Unit Offset = 0
    Controller 1 Port 1 Status = Online
    Controller 2 Port 1 Status = Online

    Note: Make sure WWNN = 22222222-22222222 and WWPN = 33333333-33333333 display a single connection. There should not be a connection with the Connection Name "unknown" for WWNN= 22222222-22222222 and WWPN = 33333333-33333333.

  6. Add static connections, with different Connection Namevalues, for each WWNN/WWPN on the ESX server.

Booting SuSE Linux Enterprise Server (SLES) 8 guest operating systems into "Linux - Safe Setting" Mode
Booting SuSE Linux Enterprise Server (SLES) 8 guest operating systems in safe mode causes SCSI resets/aborts error messages. This error can occur on some Pentium 4 machines with Hyper-Threading capabilities, and having Hyper-Threading enabled in the BIOS.

Action:
To successfully run Uniprocessor and SMP-enabled SLES8 guest operating systems, Hyper-Threading must be disabled on the ESX Server machine and the boot parameters used by the kernel must be modified on the guest operating system.

Disabling Hyper-Threading on the ESX Server
To disable Hyper-Threading, you need to modify the BIOS on the machine where the ESX Server is installed. Please refer to the documentation for your machine on how to disable Hyper-Threading, or contact the manufacturer of the machine for instructions.

Note: In the BIOS settings for some machines, Hyper-Threading is sometimes named "Logical Processor."

Once Hyper-Threading is disabled on the ESX Server machine, you need to modify boot parameters for the SLES 8 guest operating system.

Modifying the Boot Parameters on the SLES 8 Guest Operating Systems
Take the following steps after you install Uniprocessor and SMP-enabled SLES 8 guest operating systems:

  1. Boot into normal mode.
  2. As root, use a text editor and open the following file:
    /boot/grub/menu.lst
  3. Add the following parameter to the end of the failsafeline:
    noapic
  4. Reboot the virtual machine.

You can safely boot into the Linux safe setting mode.

Failed Detection of LUNs
If running Emulex HBAs on an IBM ESS Model 2105-E20 (IBM Shark), the ESX Server may fail to detect LUNs on the SAN array after a reboot. This means that you cannot discover or configure LUNs on a SAN.

Action:
The LUN discovery in SAN of ESX Server through Emulex LP9802 is dependent on the BIOs setting of the HBAs. By default, the Emulex PCI BIOS is disabled and needs to be enabled using a diagnostics utility, such as the LightPulse utility (lputil).

Slow Booting When Probing for LUNs on a Shared Fibre Channel HBA
During bootup, some Fibre Channel cards respond slowly when they are being probed for available LUNs. VMware has observed this behavior with a shared Emulex card, and this may cause ESX Server to take as long as forty minutes to boot.

Action:
Edit /etc/lilo.conf to specify one more than the highest LUN ID that you are using on your ESX Server host. By specifying one more than the highest LUN ID that is assigned in your system, LILO does not probe the Fibre Channel card for any additional LUNs beyond the actual number of LUNs in use.

Follow these steps to prevent LILO from probing beyond the highest numbered LUN on your ESX Server host:

  1. Log in to the service console as root.
  2. Use a text editor to open the following file:
    /etc/lilo.conf
  3. Locate the following line:
    append="mem=192M cpci=0:0,4,14,15,16;1:*;2:2;3:*;"

  4. Add the string: max_scsi_luns=<N+1> to the beginning of the append parameters, where N is the highest LUN ID.

    For example, if 15 is the highest LUN ID of all LUNs assigned to this ESX Server host, the append would look like this:
    append="max_scsi_luns=16 mem=192M cpci=0:0,4,14,15,16;1:*;2:2;3:*;"

  5. Run LILO to apply these changes:
    # /sbin/lilo
  6. Reboot ESX Server.

Enabling the Emulex BIOS
To enable the Emulex BIOS, you can choose one of the following options:

  • Unload and reload the Emulex driver manually after you boot the ESX Server.
    1. To manually unload the driver, enter:
      vmkload_mod -u lpfcdd.o
    2. To manually load the driver, enter:
      vmkload_mod /usr/lib/vmware/vmkmod/lpfcdd.ovmhba
  • Upgrade and enable the Utility BIOS of the HBA and reboot the ESX Server. You can download the latest LightPulse utility and BIOs from http://www.emulex.com.

Reducing the Effect of SAN Resets on Hosts
If you have configured a virtual machine to directly access a raw LUN on a SAN, and the virtual machine is using the virtual BusLogic SCSI adapter, you will see one or more resets on the SAN whenever that virtual machine boots. This behavior occurs because the BusLogic driver always issues a SCSI bus reset when it is first loaded, and this SCSI bus reset is translated to a full SAN reset.

Action:
You can reduce the effect of these SAN resets on other hosts attached to the SAN by turning on the configuration variable DiskUseDeviceReset.

To enable DiskUseDeviceReset variable:

  1. Using a Web browser, log in to the VMware Management Interface as root and click the Options tab. From the Options page, click Advanced Settings.
  2. Locate the DiskUseDeviceReset parameter and click the variable value.
  3. The Update VMkernel Parameter window opens and displays the current value: 0.
  4. In the New Value field, enter the value 1 and click Update. This saves the new setting.
Once the configuration variable is enabled, SCSI bus resets by the guest translate to resets on the specific device (disk array) containing the raw LUN, which greatly limits the effect on other uses of the SAN.

Alternatively, you can configure your virtual machine to use the LSI Logic SCSI device. The LSI Logic driver does not issue bus resets when it is first loaded. For instructions, see Configuring a Virtual Machine to Use the LSI Logic SCSI Adapter.

Using New Drivers for Smart Array Storage Controllers
ESX Server 2.1.2 installs updated drivers for a number of Smart Array storage controllers, used in ProLiant servers from HP and Compaq.

  • The cciss driver supports Smart Array 5i, Smart Array 5i+, Smart Array 532, Smart Array 5300 and Smart Array 5312 controllers, including the Smart Array 5302 and Smart Array 5304.

  • The cpqarray driver supports the Smart Array 431, Smart Array 4200, Smart Array 4250ES, RAID LC2, Smart Array 221, Smart Array 3200, Smart Array 3100ES, Smart Array 2P, Smart Array 2SL and Integrated Smart Array controllers.

Action:
Under ESX Server, these drivers can be used for disk drive arrays; however, adding and deleting logical volumes on the fly is not supported. The drivers cannot be used with tape drives.

Generic SCSI Devices
The only generic SCSI devices supported by ESX Server 2.1.2 are tape backup devices. If you plan to use tape backup devices, you must select the LSI Logic SCSI device for your virtual machine.

For a list of currently supported device families, see ESX Server 2 I/O Compatibility Guide.

Exceeded Error on HP ProLiant DL760 G2 8-Way Xeon with Hyper-Threading Enabled
If you have an HP ProLiant DL760 G2 8-Way Xeon with Hyper-Threading enabled, then it may not boot into Linux. You may see the following error message:
Warning: No sibling found for CPU 14
Enabling IO-APIC IRQs
IO_APIC#0 ID8 is already used!
Kernel Panic: Max APIC ID exceeded!
In idle task - not syncing

Action:
Boot into the BIOS of the HP ProLiant DL760 G2 and disable Hyper-Threading.

Starting, Restarting, or Stopping Master SNMP Agent After Upgrading ESX Server
After upgrading ESX Server, you may see an error message similar to the following when you start, restart, or stop the master SNMP agent through the VMware Management Interface:
One or more errors occurred. SNMP Configuration: Could not change VMware subagent status: Stopping vmware-snmpd:[FAILED] Your main SNMP daemon may not be running; it should be started before vmware-snmpd can run. To start your main agent, run: /etc/rc.d/init.d/snmpd start".

Action:

  1. If you have not done so already, log into the VMware Management Interface as the root user.
  2. Click the Options tab, then click SNMP Configuration.
  3. Disable the status of the VMware SNMP SubAgent.
  4. Then, enable the status of the VMware SNMP SubAgent.

Configuring a FAStT SAN for ESX Server
You should disable Auto-Logical Drive Transfer on a FAStT SAN when using it with ESX Server. ADT mode can cause path address errors when interacting with the default MRU multipathing policy.

Configuring a CLARiiON SAN to Identify LUNs
When you first configure ESX Server to access a CLARiiON SAN, you may encounter addressing errors in the management interface or service console. This occurs when ESX Server attempts to identify the nominal LUN on the SAN as an actual LUN. A CLARiiON SAN defines this nominal LUN by default, labeled as LUNZ by the SAN management software.

If LUNZ is present when you are creating your initial storage configuration for a CLARiiON SAN, ESX Server may identify the disk as unavailable. For example, if you connected a CLARiiON SAN and opened the Storage Management page in the management interface, in the Disks and LUNs tab you might see the following error:

Cannot create partition table for disk vmhba2:0:n because geometry info is invalid. Could not load partition table. Please rescan.

You can reconfigure your CLARiiON SAN to not create a nominal LUN. Enter the following command in the SAN management interface of your CLARiiON SAN:

navicli -h HOSTNAME storagegroup -sethost -hostname name -arraycompath 0

Include the name of your SAN after the -hostname option flag.

A CLARiiON SAN creates the LUNZ LUN when the option ArrayCommPath is enabled, which is the default configuration. You can prevent ESX Server from returning this LUN identity error by disabling ArrayCommPath.

Guest Operating System

Red Hat Linux 2.1 Advanced Server Guest Operating System Fails to Boot if Using the LSI Logic SCSI Driver
Booting Red Hat Linux 2.1 Advanced Server guest operating system shows an error that the mptbase.o and mptscsih modules fail to load.

Action:
To resolve this problem, install the latest LSI Logic SCSI driver. To download the driver packages:

  1. Go to LSI Logic download page on the Web at:
    ftp://ftp.lsil.com/HostAdapterDrivers/linux/Ultra320/2.05.00/2.05.00-rpms/mptlinux-redhat-2.05.00-1.i686.rpm
  2. Download the and install the driver package on the guest operating system.
  3. Configure your system to use the LSI SCSI adapter. Please follow the instructions at: Configuring a Virtual Machine to Use the LSI Logic SCSI Adapter.

Errors Installing VMware Tools on Windows NT 4 Server Guest Operating System
When you install VMware Tools in a Windows NT 4 Server virtual machine, you may see an error that the vmxnet driver fails to install.

Action:
Take the following steps to install the vmxnet driver:

  1. After the VMware Tools are installed, at the reboot prompt, click No.
  2. Select the option to install the tools again.
  3. Once the installation begins, cancel out of the installation.
  4. In your virtual machine, right-click Network Neighborhood and select Properties.
  5. Select the Adapter tab.
  6. Select Add. This adds a new driver.
  7. At the driver prompt, enter the location of the driver:
    C:\Program Files\VMware\VMwareTools\Drivers\vmxnet\winnt\
  8. Click OK. The vmxnet driver should now be installed.
  9. Reboot the guest operating system.

Networking Error, IP Address Already Assigned to Another Adapter
Under certain conditions, you may see the following error message from a Windows guest operating system:

The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter Name of adapter. Name of adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working. If the same address is assigned to both adapters and they become active, only one of them will use this address. This may result in incorrect system configuration. Do you want to enter a different IP address for this adapter in the list of IP addresses in the advanced dialog box?

In this message, XXX.XXX.XXX.XXX is an IP address that you are trying to set and Name of adapter is the name of a network adapter that is present in the registry but hidden in Device Manager.

This can occur when you change a network connection's TCP/IP configuration from DHCP to a static IP address if you have either upgraded VMware virtual network adapters or have added and removed network adapters multiple times.

The cause of the error is that a network adapter with the same IP address is in the Windows registry but is hidden in the Device Manager ( My Computer > Properties > Hardware > Device Manager ) This hidden adapter is called a ghosted network adapter.

Using the Show hidden devices option in the Device Manager (View > Show hidden devices) does not always show the old virtual NIC (ghosted adapter) to which that IP Address is assigned

Microsoft addresses this issue in their Knowledge Base article 269155, which is available at the time of this writing at:
http://support.microsoft.com/?kbid=269155.

Action:
To resolve this problem, follow these steps to make the ghosted network adapter visible in the Device Manager and uninstall the ghosted network adapter from the registry:

  1. Select Start > Run.
  2. Enter cmd.exe and press .
  3. At the command prompt, run this command:
    set devmgr_show_nonpresent_devices=1
  4. Enter Start DEVMGMT.MSC and press Enter.
  5. Select View > Show Hidden Devices.
  6. Expand the Network Adapters tree (select the plus sign next to the Network adapters entry)
  7. Right-click the dimmed network adapter, and then select Uninstall.
  8. Close the Device Manager.

New Virtual Machines

First create your new virtual machine, selecting the vmxnet driver. Once you have created the new virtual machine, then complete the following steps.

  1. Power on the virtual machine.
  2. Ready the VMware Tools CD-ROM ISO image. In the VMware console (application) window, select Settings > VMware Tools Install, then click Install. Click Cancel when the Setup Wizard Welcome window comes up.
  3. When you log into Windows, a Found New Hardware: Ethernet Controller message appears. Then the Found New Hardware Wizard appears. Click Next.
  4. Click Display a list of the known drivers for this device so that I can choose a specific driver , then click Next.
  5. In the Hardware Types list, select Network adapters, then click Next.
  6. In the Found New Hardware Wizard, click Have Disk.
  7. Browse to the vmxnet driver information file. By default, it's located in D:\vmnet\win2k (Windows 2000 and Windows Server 2003) or D:\vmnet\winnt (Windows NT).
  8. After you select the file, you return to the Found New Hardware Wizard. VMware PCI Ethernet Adapter is selected. Click Next.
  9. Click Next to begin installing the driver.
  10. Click Yes to acknowledge that the digital signature was not found.
  11. Click Finish.
  12. In the console window, select Settings > Cancel VMware Tools Install.

    If you check the Driver File Details for the virtual machine's network adapter, you will see that the VMware PCI Ethernet Adapter is pointing to vmxnet.sys.

Existing Virtual Machine

If you have an existing virtual machine, then complete the following steps to upgrade your vmxnet driver:

  1. Shut down the guest operating system and power off the virtual machine.
  2. If necessary, edit the virtual machine's configuration and select the vmxnet NIC in the VMware Management Interface.
  3. Save your changes.
  4. Power on the virtual machine.
  5. Ready the VMware Tools CD-ROM ISO image. In the VMware console (application) window, select Settings > VMware Tools Install, then click Install. Click Cancel when the Setup Wizard Welcome window comes up.
  6. After logging into Windows, choose Start > Settings > Network and Dial-up Connections.
  7. Right-click on the adapter name and select Properties.
  8. In the General tab, click Configure.
  9. In the Driver tab, click Update Driver. The Welcome to the Upgrade Device Driver Wizard appears.
  10. Click Next.
  11. Click Display a list of the known drivers for this device so that I can choose a specific driver, then click Next.
  12. (Windows NT only) In the Hardware Types list, select Network adapters, then click Next.
  13. In the Update Device Driver Wizard, click Have Disk.
  14. Browse to the vmxnet driver information file. By default, it's located in D:\vmnet\win2k (Windows 2000 and Windows Server 2003) or D:\vmnet\winnt (Windows NT).
  15. After you select the file, you return to the Found New Hardware Wizard. VMware PCI Ethernet Adapter is selected. Click Next.
  16. Click Next to begin installing the driver.
  17. Click Yes to acknowledge that the digital signature was not found.
  18. Click Finish.
  19. In the console window, select Settings > Cancel VMware Tools Install.
  20. If you check the Driver File Details for the virtual machine's network adapter, you will see that the VMware PCI Ethernet Adapter is pointing to vmxnet.sys.

Upgrading Windows Server 2003 Guest Operating Systems Created by ESX Server 1.5.2
If you used ESX Server 1.5.2 to create a virtual machine with a Windows Server 2003 guest operating system, then you must update the guestOS configuration parameter in the virtual machine's configuration file. Otherwise, this virtual machine will not run properly with ESX Server 2.1.2.

Action:
Complete the following steps to update the guestOS configuration parameter:

  1. Log into the VMware Management Interface as the owner of the virtual machine, or as the root user.
  2. Click the arrow to the right of the terminal icon for the Windows Server 2003 virtual machine and choose Configure Options.
  3. Click the Options tab, then under Verbose Options, click the link.
  4. Change the value of the guestOS configuration parameter to one of the following:
    • winNetWeb (Windows Server 2003 Web Edition)
    • winNetStandard (Windows Server 2003 Standard Edition)
    • winNetEnterprise (Windows Server 2003 Enterprise Edition)
  5. Click OK to save your changes.

Upgrading VMware Tools in a Linux Guest Operating System
Before upgrading VMware Tools in a virtual machine running a Linux guest operating system, you must stop networking.

Note: You do not need to complete these steps if you are installing VMware Tools for the first time.

Action:
Complete the following steps to stop networking:

  1. In the remote console window, choose Settings > VMware Tools Install.
  2. Open a terminal window and log in as the root user.
  3. Stop networking by typing the following:
    /etc/init.d/network stop
  4. Complete the VMware Tools installation.
  5. Start networking by typing the following:
    /etc/init.d/network start
  6. Exit the terminal window.

Ensuring Sufficient Swap Space in the Guest Operating System
For resource management purposes, ESX Server may increase the memory utilization within a guest operating system. Therefore, it is important to ensure that the guest operating system has sufficient swap space.

Action:
Add additional swap space in the guest operating system, equal to the difference between the virtual machine's maximum and minimum memory sizes.

Changing From the vlance to vmxnet Virtual Network Adapter in a Linux Guest Operating System
If you create a virtual machine with a Linux guest operating system and the vlance driver, and then you later decide to use the vmxnetdriver instead, then you must run the vmware-config-tools.plscript. Otherwise, the virtual machine will not be able to use the new driver.

Action:
Log into the guest operating system as the root user and run the vmware-config-tools.pl script.

"Tainted" Drivers in a Red Hat Linux 8.0 Guest Operating System
Description:
When a Red Hat Linux 8.0 guest operating system loads the vmxnet networking driver, it reports that the driver is tainted.

Action:
This does not mean that there is anything wrong with the driver. It simply indicates that this is a proprietary driver, not licensed under the GNU General Public License.

Getting a DHCP Address in a Red Hat Linux 9.0 Virtual Machine
You have a virtual machine, with Red Hat Linux 9.0 as the guest operating system and the vlance driver for your network connection. When this guest operating system tries to get a DHCP address, the attempt fails and you see an error message that states the link is down.

Action:
To work around this problem, become root (su -) and use a text editor to edit the following files in the guest operating system. If only one of these files exist, then make the change for that file only.
/etc/sysconfig/network-scripts/ifcfg-eth[n]
/etc/sysconfig/networking/devices/ifcfg-eth[n]

where, in both cases, [n] is the number of the Ethernet adapter -- for example, eth0.

Add the following section to each of these two files:

check_link_down () {
return 1;
}
Then, run the command ifup eth[n] (where [n] is the number of the Ethernet adapter) or restart the guest operating system.

Using Uniprocessor and Multiprocessor Kernels with Red Hat Advanced Server 2.1
RedHat AS 2.1 MP kernels have a bug that prevents them from always working correctly on uniprocessor systems (both native and virtual). However, they work fine on multiprocessor systems (both native and virtual). Therefore, we recommend that you always boot a uniprocessor kernel on uniprocessor systems and a multiprocessor kernel on multiprocessor systems.

Because the multiprocessor kernel is the default, ensuring that the correct kernel is selected on a uniprocessor system requires some extra steps on each boot - namely selecting the uniprocessor kernel from the boot loader menu.

Note: If you do not do this, the virtual machine is likely to hang.

Action:
When performing your Red Hat Advanced Server 2.1 installation in your virtual machine, follow the steps described in: Installing a Red Hat Linux Advanced Server 2.1 guest operating system.

Note: Be sure, if you are using a uniprocessor machine, to deselect the kernel-smp box (no asterisk between the brackets).

If you have already installed the Red Hat Advanced Server 2.1, then you must change the default kernel to match the processor system. Do not complete these steps if you correctly installed Red Hat Advanced Server 2.1 following the instructions in the preceding paragraph.

  1. Boot the virtual machine. The boot loader menu appears before the guest starts to boot.
  2. Manually, select the non-default (uniprocessor) kernel in the bootloader.
  3. Once the virtual machine is booted, as root, change the single guest configuration file: /etc/lilo.conf, if the guest is using LILO or /etc/grub.conf, if the guest is using GRUB.
    • If you use LILO to boot your Linux system, follow these steps:
      1. Use a text editor to open /etc/lilo.conf.
      2. Modify the imageline to read:
        image= /boot/vmlinuz
      3. Save the file and close your text editor.
      4. Run /sbin/lilo.
    • If you use GRUB to boot your Linux system, follow these steps:
      1. Use a text editor to open /boot/grub/menu.lst.
      2. Search for the section title linux.
      3. Insert the parameter in the line starting with kernel for each boot configuration with which you use VMware products. For example:
        title linux
        kernel (hd0,0)/vmlinuz root=/dev/hda3 vga=791apic
        initrd (hd0,0)/initrd
      4. Save the file and close your text editor.
        GRUB will read this entry during the next boot process.
  4. Reboot your guest operating system.

    From this point on, RedHat AS 2.1 will boot the uniprocessor kernel by default on the uniprocessor system. This prevents the hang.

Error Message During Device Installation of Windows Server 2003 or Windows XP Professional Guest Operating Systems
During your installation of Windows Server 2003 or Windows XP Professional as a guest operating system in ESX Server, you may see a message stating "Continuing your installation of this software may impair or destabilize the correct operation of your system either immediately or in the future. Microsoft strongly recommends that you stop this installation and contact the software vendor for software that has passed Windows Logo Testing."

Action:
Click Yes to continue to install the software. This error message is due to an unsigned BusLogic SCSI driver and can be safely ignored.

Installing a Windows 2000 Server Guest Operating System
Only Windows 2000 Server guest operating systems, with Service Pack 3 or 4 installed, are supported in ESX Server 2.1.2. If you attempt to run Windows 2000 Server, without one of these service packs, in a SMP virtual machine, then your guest operating system may fail to boot.

Action:
Install Service Pack 3 or 4 in your Windows 2000 Server guest operating system.

Running a Windows 2000 Server SP3 Guest Operating System
A Windows 2000 guest with Service Pack 3 installed may fail to boot. A user interface failure message appears, saying "The Logon User Interface DLL msgina.dll failed to load."

Action:
To work around this problem, be sure the virtual machine is not running, then use a text editor to add the following line to the virtual machine's configuration file:
MAGICBOOT1 = 700

If a value of 700(representing 700 microseconds) does not enable you to start the guest operating system, experiment with higher values. Increase the number to 800for the second try, 900for the third try and so on until the guest starts.

If you are booting multiple virtual machines or running other stressful workloads at the same time, you may need to assign a higher magicboot1 value. For faster boot times, you may experiment with values between 1 and 700 to find the smallest value that allows the virtual machine to boot.

Disable Ports COM1 and COM2 When Running Citrix MetaFrame in a Windows 2000 Advanced Server Guest Operating System
You should disable ports COM1 and COM2 if you are running Citrix MetaFrame in a Windows 2000 Advanced Server guest operating system. If you use these ports, you may see random spikes in CPU utilization, affecting your performance.

Action:
Complete the following steps to disable the COM1 and COM2 ports in the guest operating system.

  1. Power on your virtual machine and log in as the Administrator user.
  2. Right-click the My Computer icon and choose Manage. The Computer Management window appears.
  3. Click Device Manager in the left pane.
  4. In the right pane, click the plus (+) sign next to Ports.
  5. Right-click Communications Port (COM1) and choose Disable.
  6. Right-click Communications Port (COM2) and choose Disable.
  7. Click Yes in the confirmation dialog.

Using the IBM Ultrium Tape Autoloader 3581 or IBM TotalStorage Ultrium Tape Drive T400F in Windows Guest Operating Systems
If you want to use the IBM Ultrium Tape Autoloader 3581 or IBM TotalStorage Ultrium Tape Drive T400F in a Windows guest operating system, then be sure to use the LSI Logic SCSI adapter in the virtual machine.

Action:
See Configuring a Virtual Machine to Use the LSI Logic SCSI Adapter for more information.

Disable PAE in ESX Server 2.x Guest Operating Systems for Better Performance
Although ESX Server 2.x virtual machines are compatible with PAE, they are not optimized for it. As a result, guest operating systems with PAE enabled may experience poor performance. For best performance, VMware recommends that you disable PAE in guest operating systems.

Action:
For more information and instructions for disabling PAE in a guest operating system, see Knowledge Base article 2020 at http://kb.vmware.com/kb/2020.

PCI Alert Logged for IDE Controller in Dell 1850
Booting ESX Server installed on a Dell 1850 logs the following alerts when the machine reboots:
vmkernel: 0:00:00:00.000 cpu0:127) ALERT: PCI: 1598: failed for 000:31.1
vmkernel: 0:00:00:00.000 cpu0:127) WARNING: Host: 3334: irq 255 is not valid

For more information, see Knowledge Base answer 1366 at http://kb.vmware.com/kb/1366.

Reloading Drivers for Fibre Channel Adapters May Cause Kernel Fault
If you manually unload and then reload the driver for a Fibre Channel adapter, ESX Server may encounter a kernel fault. This will only occur if the adapter is connected to a SAN when you reload the driver. If this happens you must reboot your system. You can then check /var/log/messages for a kernel panic entry that corresponds to the loading of a specific driver.

Duplicate SCSI Identifiers Cause System Failure
If your server shares an external SCSI bus with other systems, you should check all servers and devices using the bus to make sure each is assigned a different SCSI ID number. Specifically, you need to determine that each SCSI adapter connected to the bus uses a unique SCSI ID. See the documentation for a particular SCSI adapter for instructions on how to set its SCSI ID.

To find the SCSI ID number of a controller installed in your server, see "Determining SCSI Target IDs" in the ESX Server Administration Guide. This section also includes steps for determining the ID of a SCSI host adapter.

Caution: Assigning a duplicate SCSI ID to a controller on another system sharing the SCSI bus with ESX Server will cause a system failure.

Using More Than 48GB of RAM in a Non-NUMA Server
If you are using ESX Server 2.1, and your system is configured with more than 48GB of memory, your system will fail during initialization. This issue is resolved in ESX Server version 2.1.2. To resolve this issue, upgrade from ESX Server version 2.1 to version 2.1.2.

Reloading Drivers for Fibre Channel Adapters May Cause Kernel Fault
If you manually unload and then reload the driver for a Fibre Channel adapter, ESX Server may encounter a kernel fault. This will only occur if the adapter is connected to a SAN when you reload the driver. If this happens you must reboot your system. You can then check /var/log/messages for a kernel panic entry that corresponds to the loading of a specific driver.

Using LSI 1020/1030 Controllers in Shared Mode with Mirrored Disks
This issue is resolved in ESX Server version 2.1.2. To resolve this issue, upgrade from ESX Server version 2.1 to version 2.1.2.

If you are using ESX Server 2.1, and you are using a LSI 1020/1030 SCSI controller in shared mode with mirrored disks, ESX Server may fail during system startup. Specifically, if the disks are initializing or re-synchronizing when you start your server, VMkernel may fail to load. Check /var/log/messages for the following error message:

mptbase: ioc0: ERROR - Doorbell ACK timeout(n)!

You can avoid this error by ensuring that the mirrored drives synchronize before or after VMkernel loads during the startup procedure. To delay synchronization, disconnect one of the disks prior to restarting ESX Server. You can then reconnect the disk and allow the mirrored disks to resynchronize.

To synchronize the mirrored disks before starting ESX Server, power on your server and enter Control-M or Control-C to open the BIOS configuration menu for the LSI controller. In the menu, check the synchronization status of the mirrored disks. When the disks are fully synchronized, exit the BIOS menu and continue the startup procedure for ESX Server.

Note: Synchronizing large disks may require a significant delay.

Using USB Devices with HP and NEC Servers
USB devices on some HP and NEC servers may be disabled when you restart your system. During startup, ESX Server detects whether installed USB devices generate interrupts that interfere with other devices. Those USB devices are automatically disabled.

You can check your system log files to determine if you have encountered this error:

  1. Log on to the management interface.
  2. Select Options > System Logs.
  3. Choose the VMkernel Warnings tab.
  4. Check the entries for IDT alerts. For example:
    IDT: 1611: Disabling vector 0xnn Each IDT: 1611 entry indicates a USB device that ESX Server disabled during startup. The last two characters are the vector identification. There may be more than one alert for each set of startup entries.

Note: Do not attempt to reenable individual USB devices as you may cause your system to fail. Check the VMware Knowledge Base for steps describing how to safely reconfigure USB devices.

Using USB When ESX Server Disables It
Due to incompatibilities with some recent chipsets, the VMkernel may disable USB interrupts in some hardware configurations. This happens with servers in which USB controllers share interrupt lines with other controllers, and the IOAPIC is designed to forward masked interrupts. During startup, the VMkernel automatically disables USB so the VMkernel can manage its interrupts more effectively.

VMware has identified the following servers exhibiting this behavior: NEC blades, NEC EXP5800, DL580, Dell 1850, Dell 2850 and Dell 2800. Other models may be affected in addition to these.

Action:
If you need to use USB on a server where the VMkernel has disabled it, see the VMware Knowledge Base answer "Using USB When ESX Server Disables It" for the steps needed to ensure that the USB controller does not interfere with other PCI controllers.

Using USB Device May Show Error During System Boot
Systems using the USB-UHCI driver device with the USB 2.0 interface will cause ESX Server to show a false warning message during the boot sequence.

Action:
To configure your system to remove this warning from appearing the next time you boot your ESX Server machine, follow these steps:

  1. As root, log on to the service console.
  2. Using text editor, open the following file:
    /etc/modules.conf
  3. Remove the following line from the configuration file:
    alias usb-controller1 usb-ohci

    The next time you boot ESX Server, you should not see the warning message.

Expired ESX Server Evaluation License
Expired ESX Server licenses may cause virtual machines to suspend and cause system downtime.

Action:
To verify that the full version license file has made it into your server, look in the following location on the service console:
/etc/vmware

There may be several license files in this directory. Use a text editor to read the details of each license file, so that you can be sure your full version has been accepted. If you like, you may also DELETE the evaluation license file from this directory. Prior to deleting the (evaluation) license file, look at the text of said file in a text editor to make sure you're deleting the right one. When your server is next rebooted, the new serial number will take effect.

Finding Service Console SCSI Devices Using vmkfstools -N Not Supported
Previous versions of ESX Server included the -N option of the vmkfstools command as a way to find the name of SCSI devices defined in the service console. This option has been removed, and you should now use the -q option of the vmkpcidivy command instead. See "Using Devices With ESX Server" in the ESX Server Administration Guide for more details.

Long Server Boot Time
If booting with 32GB of memory, you may experience a long wait time when booting the ESX Server.

No VLAN Support for 3Com NICs
3Com Fast Ethernet NICs do not support VLANs.

Avoid Using the Keyboard and Mouse When the ESX Server VMkernel Loads
When starting the ESX Server and the VMkernel is loading, avoid using the keyboard or mouse. If used, you may find that the keyboard or mouse do not function once the VMkernel is loaded. Action:
To activate your keyboard or mouse, follow these steps:

  1. Using a Telnet or SSH connection, access the service console as root.
  2. To active the keyboard, enter the following command:
    echo SetHostIRQ 1 >/proc/vmware/chipset
  3. To active the mouse, enter the following command:
    echo SetHostIRQ 12 >/proc/vmware/chipset

VMware Management Interface Not Able to Manage a Partition Once it is Changed by fdisk
If you used fdisk from the command-line to manage partitions, then you must restart the vmware-serverd process. Otherwise, you will be unable to manage the disk partitions using the VMware Management Interface for up to fifteen minutes.

Action:
By default, the vmware-serverd process reports disk partition configuration changes every fifteen minutes. To view and manage disk partitions immediately, you must restart the vmware-serverd process by logging in to the service console as root and issuing the command killall -9 vmware-serverd.

Note: The vmware-serverd process will restart automatically upon requests from any of its clients.

The ESX Server Hangs when the vmkernel Loads on HP DL Series Servers
If you are using Hewlett_Packard DL-740 and Hewlett-Packard DL-760 G2HP series servers, and the ESX Server software hangs when vmkernel loads, the BIOS version of the server hardware may not be compatible with the ESX Server 2.x software.

Action:
Please check the BIOS version and processor speed(s) of your server hardware. If needed, upgrade or downgrade to the compatible BIOS version.

Note: Both of the above BIOS revisions support processors 1.5GHz or faster.

Running Many Virtual Machines on ESX Server
If you are running a lot of virtual machines on ESX server, then complete the following items, to allow ESX Server to operate more efficiently.

  • If you notice a degradation in system performance, then you should increase the CPU minimum for the service console.
  • Log into the VMware Management Interface as root, click the Options tab, then click Service Console Settings and increase the minimum CPU resource settings.

  • Remove the CD-ROM drive in your virtual machines.

    If, when powering on a large number of virtual machines, you remove the CD-ROM drives from your virtual machines' configuration, then the load on the service console decreases.

  • Read and complete the section Running Many Virtual Machines on ESX Server.

    This section explains how to provide additional CPU and memory resources to the service console.

If, after changing these settings, you are still unable to open the VMware Management Interface to your server, then the number of outstanding processes, that are waiting to be executed, is too high. You need to allocate the necessary CPU resources to the management interface, by increasing the priority for the vmware-serverd and httpd processes.

Action:

  1. Log in as the root user on the service console.
  2. Type ps auxw and find the process IDs of the httpd and vmware-serverd processes.
    If there are multiple httpd processes, then type top. Click Shift-p (P) to sort the output by CPU usage. Remember the process ID for the httpd process using the most CPU.
  3. Raise the vmware-serverd process priority to -15 so that it can connect to all running virtual machines:
    renice -15 -p <vmware-serverd_process_ID>
  4. Raise the httpd process priority to -15:
    renice -15 -p <httpd_process_ID>
  5. Verify that you can log into the VMware Management Interface and view correct information about the virtual machines. Once this occurs, then continue with the next step.
  6. Change the vmware-serverd process priority back to the default of zero (0).
    renice 0 -p <vmware-serverd_process_ID>
  7. Change the httpdprocess priority back to the default of zero (0).
    renice 0 -p <httpd_process_ID>

Avoiding Management Interface Failures when Many Virtual Machines Are Registered
If you have a very large number of virtual machines registered on a single ESX Server machine, the VMware Management Interface may shut down and a Panic out of memory message may be recorded in /usr/lib/vmware-mui/apache/logs/error_log.

By default, the Apache Web server uses 24MB of memory to store information about the virtual machines on the server. The errors described above can happen when this memory is not adequate for the number of virtual machines.

Action:
To work around the problem, open the file /etc/vmware/config in a text editor and find the line that begins with mui.vmdb.shmSize =. Increase the number in quotation marks, which is specified in bytes of memory. Then restart the Apache server with the following command:
/etc/rc.d/init.d/httpd.vmware restart

Registering and Unregistering Virtual Machines
Only the root user can register and unregister virtual machines through the VMware Management Interface. However, regular users can register and unregister virtual machines by using the Scripting API.

Powering on a Virtual Machine Fails Because of an Invalid Ethernet Device
While powering on a virtual machine, you see the following message in a pop-up window:

"Failed to initialize ethernet _n. This is most likely because the appropriate ethernet driver is not loaded in the vmkernel, or the ethernet device is being used in exclusive mode by another virtual machine, or you have exceeded the limit of 32 virtual machines per ethernet device."

Action:
Click OK twice, for this pop-up window and the next pop-up window. The virtual machine boots, but you will not be able to use the Ethernet driver that was detected as invalid.

You see this error message if:

  • The vmnic is already part of a bond.
  • The vmnic or bond doesn't physically exist.
  • The bond hasn't been configured.

To fix this problem, edit the virtual machine's configuration through the VMware Management Interface and select an available vmnic or bond.

Logging into the VMware Management Interface May Fail
After a long wait with the message "Connection lost: Connection terminated by server", the log in may fail.

Action:
If you encounter this error, you must restart the HTTP daemon. Log in to the service console (either at the ESX server machine or over a Telnet or SSH link) and issue this command:
/etc/rc.d/init.d/httpd.vmware restart

Remote Console May be Disconnected or Show Errors
When the ESX Server machine is under heavy load the remote console may be disconnected or show errors. This behavior helps protect the virtual machines and the ESX Server software from failure.

Action:
If you encounter this problem, wait until the load on the server decreases, then reconnect the remote console to the virtual machine.

Don't Place VMware Core Dump and Swap Files on a SAN Disk
Do not place your VMware core dump file or swap file on a SAN disk.

Unloading the Emulex Fibre Channel HBA Driver
ESX Server may fail to shut down cleanly when unloading the Emulex Fibre Channel HBA driver.

Scanning a vmhba adapter for Devices and LUNs
Do not rescan any non-Fibre Channel adapters with the vmkfstools --scancommand. This command is intended only for Fibre Channel adapters. Rescanning, on some non-Fibre Channel adapters may cause this command to hang.

Using Fibre Channel Cards
Always use Fibre Channel cards in dedicated mode. We do not recommend sharing Fibre Channel cards between the service console and the virtual machines.

Using e1000 Network Interface Cards with the Service Console
You are using the e1000 network interface card (NIC) with the service console and have no network connection, or the output of lspci shows "Unknown device".

Action:
Manually specify the e1000 driver by adding alias<eth_number> e1000 (typically alias eth0e1000) to the /etc/modules.conf file.

Setting the DiskMaxLUN Configuration Setting Greater than 8 in an IBM x120 Blade Server
If you have configured the DiskMaxLUN configuration setting to be greater than 8 (the default), and ESX Server hangs when the VMkernel is booting, then you need to change the DiskMaskLUNs setting.

Action:
You need to mask out all LUNs except LUN0 for the target that has the processor device.

  1. Log into the VMware Management Interface as root.
  2. Click the Options tab, then click Advanced Settings.
  3. Find the DiskMaskLUNs setting and mask the appropriate LUNs.
    For example, set DiskMaskLUNs to vmhba0:8:1-255; as its value.

By setting the DiskMaskLUNs configuration setting, it overrides the DiskMaxLUN setting for all HBAs that have a LUN mask.

Importing Files Larger than 2GB
The file manager in the management interface may display incorrect information or no information at all for files larger than 2GB. This means that you cannot use the file manager to import certain virtual disk files created under VMware Workstation 4.

Action:
To import large files, from the ESX Server service console use the vmkfstools -i <srcFile> command. For details, see File System Management on SCSI Disks and RAID.

Viewing Help Topics on a Linux Management Workstation
If you launch help from the remote console on a Linux management workstation and click Contents, you see an abbreviated list of topics.

Action:
To see the full list of topics, click the Help Index link at the bottom of the Contents page.

Using the vdf Command to Display Free Space for All Mounted File Systems
vdfis an ESX Server-customized version of the df command. Use vdf in place of the dfcommand. vdf works with all the standard df options.

Using Persistent Bindings with Shared HBAs Not Supported
For this release, using persistent bindings with shared host bus adapters (HBAs) is not supported.

Fibre Channel Adapters Disconnected During Installation
In the VMware ESX Server Administration Guide, the section "Installing ESX Server With Attached SANs" cautions you to disconnect Fibre Channel adapters prior to installation. This is no longer necessary. In this release you can install ESX Server with Fibre Channel adapters connected to your system.