Features |
Technical Resources |
Knowledge Base |
Discussion Forums
What's in These Release Notes
Build 11548 is the current release build of VMware ESX Server 2.5. The release notes cover the following topics.
What's New in ESX Server 2.5
- Boot From SAN
ESX Server can now run on diskless servers by booting off of a
disk on the SAN. This greatly enhances support for common
blade and rack mount configurations.
- Improved support for raw LUNs as virtual disks using Raw Device Mappings
(RDMs) in Physical and Virtual compatibility modes.
ESX Server version 2.5 includes new features for using RDMs:
- Allows raw disks to be managed as easily as virtual disk files
- VMotion can now be used to migrate virtual machines using raw LUNs
- Improves VirtualCenter support of clustered virtual machines
- Physical compatibility RDMs enable SAN replication software to run inside
of virtual machines
- Virtual compatibility RDMs enable backup offloading solutions so that
ESX Servers can be backed up faster without any load placed on
the virtual machines or the on Service Console
- Allows REDO logs to be added to raw disks
For details on how to use these new features, see
"Accessing Raw SCSI Disks".
- Enhanced support for scripted installations
Allows third-party systems management products to remotely install
and configure ESX systems. See
"Scripting Your Installations" for more details.
- Improved Support for Clustered Virtual Machines
MSCS clustering of virtual machines using shared disk access is now more reliable.
- Additional Support for Disaster-Recovery Backups or Virtual Disks
Virtual disk snapshot scripts added to the Service Console to
enable crash consistent backups of entire virtual machines.
- Revised Compatibility Guides
This release includes updated compatibility guides listing the new hardware supported by ESX Server 2.5:
- Support for Additional Guest Operating Systems
ESX Server version 2.5 now supports these operating systems in virtual machines.
-
FreeBSD 4.9 (Uniprocessor mode only)
-
SuSE Linux Enterprise Server 9
-
Windows 2003 Small Business Server
- Improved SSH Security
ESX Server version 2.5 now uses SSH Protocol Version 2 as the default secure login client.
Finding the Latest Known Issues
Check the VMware Knowledge Base for updates on the issues described in this document. See the article titled
Latest Known Issues for more information.
Before You Begin
Management Agents
Known Issues with This Release
Installation
Configuration
Guest Operating System
Operation
Security Alerts for This Release
Errata to the Release Documentation
Installation Notes for This Release
Configuring Your System to Install Boot-From-SAN
For general instructions on configuring ESX Server for boot-from-SAN operation, see the
ESX Server SAN Configuration Guide.
Configuring System Partitions for Boot-From-SAN
The new boot-from-SAN features of this release allow you to use different methods of creating standard
system partitions, such as those devoted to memory swap space for virtual machines or the Service Console, or to store
core dump files. See Knowledge Base Article 1506,
www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1506, for the best practices to use when planning your
system partitions for ESX Server 2.5.
Configuring IBM BladeCenter to Install Boot From SAN
To configure your system to boot from a SAN LUN, you must ensure that the boot LUN is the first volume accessed
when you start your system. For most servers, the boot volume can be identified by setting the system BIOS. For an
IBM BladeCenter server, you must also disable the IDE controller in the BIOS. If you do not, the system will attempt to
boot from the internal IDE disc regardless of whether you designated an external boot volume.
Configuring an EMC Symmetrix SAN to Install Boot From SAN
On a Symmetrix SAN, there is normally a SAN management LUN present as the lowest numbered LUN. This can
interfere with ESX Server seeking the boot LUN in a boot-from-SAN installation. See Knowledge Base Article 1471,
www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1471,
for more details.
Disk Controllers Default to Shared Mode
In this release, ESX Server now applies shared mode as the default configuration for SCSI and FibreChannel host bus adapters.
During a standard installation, the installer initially sets all controllers to shared mode, but they can still be assigned exclusively to virtual
machines or the Service Console.
During an upgrade, the installer will also set all controllers to shared mode, even if they were not in shared mode
previously. You must reconfigure the controllers if you wish to assign them to virtual machine or the Service Console.
Note: Using raw disks with FibreChannel adapters in shared mode is not supported in this
release of ESX Server. You should check the mode of your FibreChannel adapters after installation if you
use them to access LUNs as raw disks.
Installing ESX Server on IBM BladeCenter and HP Blade Servers
For information on using ESX Server with blade servers, see
Installing and Configuring HP Blade Servers
and Installing and Configuring 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.
Use the "Text-mode" Installation Option if Installing on Systems Using an IBM Remote Supervisor Adapter II Card
If you are installing ESX Server on a system with an RSA II card, use the text-mode installation method.
Choosing the graphical installation method is not supported on the following servers:
- IBM xSeries 445 with optional RSA II
- IBM xSeries 345 with optional RSA II
- IBM xSeries 336
- IBM xSeries 346
- IBM xSeries 365
Upgrading ESX Server 2.5 Beta 1 and RC Versions on Boot-From-SAN Configured Systems
When upgrading ESX Server 2.5 Beta 1 and RC releases to version 2.5 GA, you should not boot into
the Linux boot kernels (linux and linux-up). Use the safe mode boot option
esx-san-safe. When the esx-san-safe boot option is selected, ESX Server boots into a safe mode
that allows you to upgrade your system.
Upgrading a Previous ESX Server Release to ESX Server 2.5
ESX Server 2.5 supports upgrading from the following previous releases:
To upgrade from previous versions of ESX Server to ESX Server 2.5, 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 a Previous Release of ESX Server" in the ESX Server Installation Guide.
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.
- Reboot into linux.
/sbin/reboot
- Log in as root.
- 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.
- Save the file esx-2.5.0-11343-upgrade.tar.gz to this directory.
- Change to the download directory.
- Extract the contents of the file.
tar zxf esx-2.5.0-11343-upgrade.tar.gz
- Change to the directory esx-2.5.0-11343-upgrade.
- Run the upgrade script.
./upgrade.pl
- You see various messages about the upgrade process.
- 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.5.
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.
Management Agents
Installing HP Insight Management
Agents on the Service Console
ESX Server 2.5 supports HP Insight Management Agents,
and provides a script for installing them on the service console.
For further information on installing HP Insight Management
Agents on the service console, see
Configuring Management Agents for ESX Server 2.5.
Installing Dell OpenManage
Management Agents on the Service Console
ESX Server 2.5 supports Dell OpenManage Management Agents.
For further information on installing Dell OpenManage
Management Agents on the service console, see
Configuring Management Agents for ESX Server 2.5.
Installing IBM Director Management Agents on the Service Console
ESX Server 2.5 supports IBM Director Management Agents.
For further information on installing IBM Director Management Agents
on the service console, see
Configuring Management Agents for ESX Server 2.5.
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 an 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.
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.
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.
Uninstalling HP Insight Manager Uninstalls SNMP
When you first ran the hpmgmt.sh script to install the Hewlett-Packard Insight Manager package, it upgraded the SNMP packages that were supplied with the ESX Server installation. The packages ucd-snmp-utils-4.2.5-7.72.0 and ucd-snmp-4.2.5-7.72.0 were upgraded to ucd-snmp-cmaX-utils-4.2.5-143.rh73 and ucd-snmp-cmaX-4.2.5-143.rh73.
When you ran the hpmgmt.sh script to uninstall the HP Insight Manager package, it removed the upgraded SNMP packages, leaving no SNMP installed.
Action:
You can work around the problem by installing the original SNMP packages from the ESX Server installation CD. Follow these steps:
- Open a terminal window and log on as root.
- Delete /etc/snmp/*.
- Insert the ESX Server installation CD and mount it.
- Copy the SNMP packages to your /tmp directory:
cp /mnt/cdrom/VMWare/RPMS/ucd-snmp-utils-4.2.5-7.72.0.i386.rpm /tmp
cp /mnt/cdrom/VMWare/RPMS/ucd-snmp-4.2.5-7.72.0.i386.rpm /tmp
- Install the packages:
rpm -i /tmp/ucd-snmp-4.2.5-7.72.0
rpm -i /tmp/ucd-snmp-utils-4.2.5-7.72.0
- Run the /usr/bin/snmpsetup.sh install script. This sets up snmpd and the vmware-snmpd sub-agent.
Installing on a System with a Symbios
sm53c8xx Controller
To install ESX Server 2.5 on a system with
a Symbios sym53c8xx controller, follow one of these
procedures. To install ESX Server for the first time on your system, you will need to use a driver update disk:
- Download the sym53c8xx-1.7.3c-for-ESX-2.5 Driver Disk from
www.vmware.com/download/esx/.
- Copy the disk image to a floppy disk following the instructions on the download page.
- Use the driver update disk during the installation procedure as detailed in
Installing Additional Drivers from the VMware Driver Disk.
Note: Installing the Symbios driver from the update disk will take substantially longer
than other driver updates. After the installer displays "Installing Symbios driver...,"
the actual driver installation may take up to three minutes to complete.
To upgrade a previous installation of ESX Server, you must download an upgrade tar archive and use
that to update your system. Upgrading from the release CD-ROM is not supported
for ESX Server 2.5 on a system with a Symbios sym53c8xx controller. Download the upgrade
archive esx-2.5.0-11343 from the vPlatform section of the VMware Download Center and upgrade your system following the instructions.
Installing on an HP ProLiant BL20pG3
You must use an external CD-ROM drive to install ESX Server 2.5 on
an HP ProLiant BL20pG3. You cannot use an iLO (Integrated Lights-Out)
virtual media device.
"Unresolved Symbols" Error When Upgrading From ESX Server 2.0 to ESX Server 2.x
You may see the following error message after you upgrade from ESX Server version 2.0 to ESX Server version 2.x:
Unresolved symbols in /lib/modules/2.4.9-vmnix2/kernel/drivers/scsi/qla2x00.o
Action:
You will see this error message the first time you boot ESX Server. You can safely ignore this message. The next time you reboot the server, you will not see this message.
No Virtual Ethernet Switches Found After Upgrade
When you upgrade to ESX Server version 2.5, the VMware Management Interface displays the following
warning message on the Status Monitor page:
Warning: No virtual ethernet switches found. Reconfigure...
This message appears after you upgrade because previous versions of ESX Server did not support the
concept of virtual switches. Virtual machines were assigned directly to physical (vmnic) or
virtual (vmnet) network adapters. To create new virtual machines in ESX Server version 2.0.1
or later, you need to create a virtual switch, and then configure a virtual machine to use that switch.
Note: Any previously created virtual machines referring to vmnic and vmnet names
will still function properly.
To create and configure virtual switches, use the management interface. Use the Network
Connections option to configure the network connections. This option allows you to create
new virtual switches or edit existing switches. For more information, refer to "Changing
Network Connections" at /support/esx25/doc/esx25admin_mod_network_server.html.
Configuration
Using IBM BladeCenter with QLogic FibreChannel Switches
This version of ESX Server may not identify LUNs correctly when used on IBM BladeCenter servers with internal QLogic
SanBox2 switches. When
accessing a LUN through the internal QLogic SanBox 2 switch, ESX Server may not detect all paths available in
a multipathing configuration. This is a known issue with the QLogic Version 6.07
driver.
Action:
Use the QLogic Version 6.04 driver instead. Contact VMware Support for instructions if necessary.
Using Adaptec SCSI Cards with ESX Server
To use certain Adaptec SCSI adapter cards with ESX Server, you need to perform additional
configuration steps in order to have the SCSI cards recognized by the aic79xx driver. This information
applies to the following adapter cards:
- Adaptec SCSI Card 39320-R
- Adaptec SCSI Card 39320A-R
- Adaptec SCSI Card 29320ALP-R
Action:
To have these SCSI cards recognized by the aic79xx driver, you must enter into the BIOS of the Adaptec
card and disable the HostRAID option for each SCSI card. If the HostRAID option is not disabled, Adaptec cards
are not recognized and any disks attached to the adapter are inaccessible.
To disable the HostRAID option, perform the following steps:
- Boot the ESX Server. When the computer is booting, the system displays a banner for the Adaptec HostRAID card, like the following:
Adaptec SCSI BIOS v4.10.1 © 2002 Adaptec, Inc. All Rights Reserved.
Press <Ctrl><A> for SCSISelectTM Utility!
- Press Ctrl-A. A menu displays and lists the adapters on the card.
- Use the arrow keys to select one of the adapters. For example:
39320 A at Slot 02 01:06:00
- Press Enter. An Options menu displays.
- Use the arrow keys to select Disable HostRAID Support.
- Press Enter.
Note: If the Options menu displays Enable HostRAID Support, then HostRAID is already disabled.
- After disabling HostRAID on one adapter, press ESC to return
to the adapter menu.
- Use the arrow keys to select the next adapter and disable HostRAID on any remaining adapters. Complete Steps 3 thru 6 for each Adaptec adapter listed in the menu.
- Select Exit to exit the Adaptec BIOS. The system automatically reboots.
MSCS Clustering on IBM Enterprise Storage Servers
This version of ESX Server does not support MSCS clustering on IBM Enterprise Storage Servers. VMware
recommends that online maintenance not be performed on the IBM Enterprise Storage Server when attached to
ESX Server 2.5 with MSCS clustered Windows virtual machines.
Configuring Virtual Machines with SCSI Reset Options
This release includes a new
configuration option, scsin.resetMode, that allow you to modify
how ESX Server handles SCSI bus resets issued by a virtual machine.
The resetMode option sets a virtual adapter to synchronous or asynchronous mode. For example, to set the mode
of virtual adapter 1, you would set scsi1.resetMode to a value of 0 for asynchronous mode and 255 for
synchronous mode. The default value is 255.
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.5 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:
- As root, log in to the service console.
- 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.
- Open the configuration file with the filename displayed by grep.
- Append the following configuration string to the end of the file:
DHCPCDARGS="-t 125"
- Save and close the configuration file.
You need to set DHCPCDARGS for each Broadcom adapter assigned to the service console that is using DHCP.
Configuring Bond Failover on Dell 1855 Servers
Due to how Dell 1855 servers detect network connection failures, a network adapter bond may
not failover when the primary adapter is disconnected from an external switch. This release of
ESX Server include a new option to detect network connection failures on these Dell servers.
Action:
You need to set the Net.Zerospeedlinkdown option to a value of 1 on Dell
1855 servers.
- Log into the VMware Management Interface as root.
- Click the Options tab, then click Advanced Settings.
- Find the Net.Zerospeedlinkdown option and set it to 1.
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 Name set to Linux.
Action:
To set the Profile Name for a connection, perform the following setup tasks.
- 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.
- 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.
- 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.
- Create a static connection:
ADD CONNECTION ESX_CONN_1 WWNN=22222222-22222222 WWPN=33333333-33333333
PROFILE=LINUX
- 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.
- 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 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:
- Boot into normal mode.
- As root, use a text editor and open the following file:
/boot/grub/menu.lst
- Add the following parameter to the end of the failsafe line:
noapic
- 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, 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).
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.
- To manually unload the driver, enter:
vmkload_mod -u lpfcdd.o
- To manually load the driver, enter:
vmkload_mod /usr/lib/vmware/vmkmod/lpfcdd.o vmhba
- 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.
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:
- Log in to the service console as root.
- Use a text editor to open the following file:
/etc/lilo.conf
- Locate the following line:
append="mem=192M cpci=0:0,4,14,15,16;1:*;2:2;3:*;"
- 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:*;"
- Run LILO to apply these changes:
# /sbin/lilo
- Reboot ESX Server.
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:
- 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.
- Locate the DiskUseDeviceReset parameter and click the variable value.
- The Update VMkernel Parameter window opens and displays the current value: 0.
- 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.
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:
- If you have not done so already, log into the VMware Management Interface as the root user.
- Click the Options tab, then click SNMP Configuration.
- Disable the status of the VMware SNMP SubAgent.
- 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.
Enabling SSH1 Secure Access Service
By default, ESX Server disables secure access using Version 1 of the SSH Protocol. You can reenable
SSH1 access by editing the SSH system configuration file /etc/ssh/sshd_config.
Action:
Edit /etc/ssh/sshd_config to disable the Protocol declaration limiting SSH1 access:
- Log in to the service console as root.
- Use a text editor to open the following file:
/etc/ssh/sshd_config
- Locate the following line at the bottom of the file:
Protocol 2
- Insert a pound character (#) in front of the declaration to disable it:
#Protocol 2
Note: There are two Protocol declarations in the file. Edit the declaration that
refers only to Protocol 2.
- Save /etc/ssh/sshd_config.
- From the command line, enter:
# service sshd restart
This restarts the SSH daemon.
Guest Operating System
Use BusLogic Virtual Adapters with SuSE Linux 9.1 Professional and
SuSE Enterprise Server 9
In this release, LSI Logic virtual adapters are not compatible with SuSE Linux 9.1 Professional and
SuSE Enterprise Server 9.
Action:
Configure your virtual machine to use a BusLogic virtual SCSI adapter if you wish to install SuSE Linux 9.1 Professional
or SuSE Enterprise Server 9.
Red Hat Linux 2.1 WS Guest Operating System Fails
to Install with BusLogic Virtual Adapter
Installations of Red Hat Linux 2.1 WS guest operating
system fail to complete. For virtual machines using BusLogic virtual SCSI adapters with a vlance network
adapter, the installation application never
prompts for a second installation disc.
Action:
Use a BusLogic virtual SCSI adapter with a vmxnet network adapter, or use an LSI Logic adapter with either a vmxnet
or vlance network adapter.
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:
- 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
- Download the and install the driver package on the guest operating system.
- 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.
Installing Updates to Red Hat Enterprise Linux 3.0
This release of ESX Server supports Update 1 and Update 3 to Red Hat Enterprise Linux 3.0. Update 2 is not
supported.
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:
- After the VMware Tools are installed, at the reboot prompt, click No.
- Select the option to install the tools again.
- Once the installation begins, cancel out of the installation.
- In your virtual machine, right-click Network Neighborhood and select Properties.
- Select the Adapter tab.
- Select Add. This adds a new driver.
- At the driver prompt, enter the location of the driver:
C:\Program Files\VMware\VMwareTools\Drivers\vmxnet\winnt\
- Click OK. The vmxnet driver should now be installed.
- Reboot the guest operating system.
Build Number Mismatch When Installing VMware Tools on FreeBSD Guest Operating Systems
The build number of the version of VMware Tools installed in a FreeBSD virtual machine may not match the build number
of this release of ESX Server. VMware Tools is maintained as a separate component of ESX Server, however, and unmatched build
numbers do not indicate that either VMware Tools or ESX Server needs to be updated.
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:
- Select Start > Run.
- Enter cmd.exe and press .
- At the command prompt, run this command:
set devmgr_show_nonpresent_devices=1
- Enter Start DEVMGMT.MSC and press Enter.
- Select View > Show Hidden Devices.
- Expand the Network Adapters tree (select the plus sign next to the Network adapters entry)
- Right-click the dimmed network adapter, and then select Uninstall.
- 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.
- Power on the virtual machine.
- 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.
- When you log into Windows, a Found New Hardware: Ethernet
Controller message appears. Then the Found New Hardware Wizard appears. Click Next.
- Click Display a list of the known drivers for this device so that I can choose a specific driver , then
click Next.
- In the Hardware Types list, select Network adapters, then click Next.
- In the Found New Hardware Wizard, click Have Disk.
- 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).
- After you select the file, you return to the Found New Hardware Wizard. VMware PCI Ethernet Adapter is
selected. Click Next.
- Click Next to begin installing the driver.
- Click Yes to acknowledge that the digital signature was not found.
- Click Finish.
- 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 Machines
If you have an existing virtual machine, then complete
the following steps to upgrade your vmxnet driver:
- Shut down the guest operating system and power off the virtual machine.
- If necessary, edit the virtual machine's configuration and select the vmxnet NIC in the VMware Management
Interface.
- Save your changes.
- Power on the virtual machine.
- 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.
- After logging into Windows, choose Start > Settings > Network and Dial-up Connections.
- Right-click on the adapter name and select Properties.
- In the General tab, click Configure.
- In the Driver tab, click Update Driver. The Welcome to the Upgrade Device Driver Wizard appears.
- Click Next.
- Click Display a list of the known drivers for this device so that I can choose a specific driver, then
click Next.
- (Windows NT only) In the Hardware Types list, select Network adapters, then click Next.
- In the Update Device Driver Wizard, click Have Disk.
- 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).
- After you select the file, you return to the Found New
Hardware Wizard. VMware PCI Ethernet Adapter is selected. Click Next.
- Click Next to begin installing the driver.
- Click Yes to acknowledge that the digital signature was not found.
- Click Finish.
- 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.
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.5.
Action:
Complete the following steps to update the guestOS configuration parameter:
- Log into the VMware Management Interface as the owner of the virtual machine, or as the root user.
- Click the arrow to the right of the terminal icon for the Windows Server 2003 virtual machine and choose Configure Options.
- Click the Options tab, then under Verbose Options, click the link.
- 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)
- Click OK to save your changes.
Using LSI Logic Virtual Adapters with Netware Guest Operating System
Installations of Netware 5.1 with Service Pack 6 may fail for virtual machines using LSI Logic virtual
adapters. If an installation of Netware 5.1 fails,
check in the log of the virtual machine for the error
message:
LSILogic: unable to find a free reply MFA for config
page access
Action:
Set the lsilogic.doorbellIntDelay configuration parameter to a value
of 0 for the virtual machine.
For details on how to check the log of a virtual machine,
see Viewing a Log of a Virtual
Machine's Events. To set the doorbellIntDelay option,
see Modifying the
Configuration File Directly.
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:
- In the remote console window, choose Settings > VMware Tools Install.
- Open a terminal window and log in as the root user.
- Stop networking by typing the following:
/etc/init.d/network stop
- Complete the VMware
Tools installation.
- Start networking by typing the following:
/etc/init.d/network start
- 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
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]
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.
- Boot the virtual machine. The boot loader menu appears before the guest starts to boot.
- Manually, select the non-default (uniprocessor) kernel in the bootloader.
- 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:
- Use a text editor to open /etc/lilo.conf.
- Modify the imageline to read:
image= /boot/vmlinuz
- Save the file and close your text editor.
- Run /sbin/lilo.
- If you use GRUB to boot your Linux system, follow these steps:
- Use a text editor to open /boot/grub/menu.lst.
- Search for the section title linux.
- 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=791 apic
initrd (hd0,0)/initrd
- Save the file and close your text editor.
GRUB will read this entry during the next boot process.
- 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.5. 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.
- Power on your virtual machine and log in as the Administrator user.
- Right-click the My Computer icon and choose Manage.
The Computer Management window appears.
- Click Device Manager in the left pane.
- In the right pane, click the plus (+) sign next to Ports.
- Right-click Communications Port (COM1) and choose Disable.
- Right-click Communications Port (COM2) and choose Disable.
- 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
To use the IBM Ultrium Tape Autoloader 3581 or IBM TotalStorage Ultrium Tape Drive T400F in a Windows guest
operating system, 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.
Configuring Virtual Machines for Larger Screen Resolutions
You can now enable larger screen resolutions in a virtual machine. A screen resolution of 1600X1200 is supported, provided
you allocate sufficient memory to the virtual VRAM for the virtual machine. The suggested option settings for a 1600X1200
screen display are:
svga.maxWidth = 1600
svga.maxHeight = 1200
svga.vramSize = 7680000
For details on how to set these options with the Management Interface,
see Modifying the
Configuration File Directly.
Note: These resolution options are not supported in virtual machines using Netware and FreeBSD guest operating systems.
IOzone Stress Test Displays Read Error for Red Hat 8 Virtual Machine
Red Hat 8 guest operating systems can see a read error when running heavy I/O loads using the IOzone
stress test for extended periods of time. It is a read error and does not corrupt the disk. This error
does not occur on other versions of Linux or other guest operating systems or when using other stress
tests of a similar nature.
Operation
Using the vmsnap and vmres Commands
The vmsnap and vmres commands are standard implementations of the ESX Server perl APIs. They
are provided on the install CD for the convenience of our customers and operate separately from the
ESX Server product. As we refine and improve these scripts they will be posted on the
ESX Server download page.
If backup script improvements are of interest, please check the
ESX Server download page periodically.
Using Raw Device Mappings with FibreChannel Adapters
Using raw device mappings with FibreChannel adapters in shared mode is not supported in this release.
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 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:
- As root, log on to the service console.
- Using text editor, open the following
file:
/etc/modules.conf
- 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.
Service Console Disk Access on HP EVA SAN Fails After Reconfiguration
If you change the visibility of a LUN on an HP EVA SAN that has been "presented" to ESX Server with the HP Command View
management system, accessing the LUN from the Service Console may fail. ESX Server incorrectly identifies the LUN
as unavailable due to an access path failure and attempts to reconnect with the LUN instead of returning a failed access.
This is a known issue. For details on managing LUN visibility to ESX Server with Command View, see "Presenting a Host" in the
HP StorageWorks Enterprise Virtual Array User Guide.
Action:
At this time, the only method of halting the LUN reconnect cycle is to reboot ESX Server.
Manually Unloading QLogic Driver May Cause System Failure
Manually unloading QLogic driver Version 6.04 from the Service Console may cause your
system to fail. The exact conditions of this error are being determined. Please check these
release notes for updates on this error.
Clustering a Physical Machine with a Virtual Machine
This release of ESX Server supports clustering a physical machine with a virtual machine (i.e.,
an N+1 cluster). You can do this following the steps in
Two Nodes with Microsoft Cluster Service on Separate ESX Server Machines. You need to
be sure, however, that you create the first cluster node on the virtual machine, then
configure the second node on the physical machine.
Due to this restriction, you cannot join a virtual machine to an extant cluster hosted
on a physical machine.
If the Windows Cluster Administrator displays the error “The quorum disk could not be located
by the cluster service,” you need to set up the cluster again, making sure
that the virtual machine is the first node.
Service Console Disk Access Fails with "attempt to access beyond end of device" Error Message
When accessing a LUN in the Service Console, if the size of the LUN is approximately 1TB the disk access may fail.
Check the system log file /var/log/messages. If the log file contains the error
message "attempt to access beyond end of device," you have encountered a known issue in which accessing a LUN between 1TB
and 1.000002TB in size may fail.
Action:
When initializing large LUNs, create them with a partition size less than 1TB or greater than 1.000002TB.
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.
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.
VLAN Tags Incorrectly Sized
This release adds extra padding to small VLAN packets to compensate for some
network adapters which fail to pad sufficiently in some cases.
Removing Core Dump Partition Causes System Failure
Once you select a core dump partition, ESX Server requires that partition to be available. You
must explicitly disable a core dump partition before you remove or reconfigure it. Removing an active
core dump partition may cause your system to fail.
This is primarily an issue when one core dump partition is shared between servers. You must disable the
core dump partition on all servers using it before making any changes to the partition.
Action:
Disable the core dump partition with vmkdump before you reconfigure it.
Log in to the Service Console as root and enter the command:
# vmkdump -p none:0:0:0
Repeat this on every server using the shared core dump partition. When all
servers accessing the shared partition have disabled it, then you can remove or reconfigure
the partition. After you reconfigure the dump partition, or create a new one, you can activate it on each server
with another vmkdump -p command. See the vmkdump manual page for more details.
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.
VMware Management Interface File Manager Does Not Display All Virtual Disks
If you make a large number of virtual disks available to ESX Server, scanning them to list all available
disks in the VMware Management Interface File Manager may exceed the maximum scan time limit. You can store many virtual disks
in a single VMFS, but slow access to the physical LUNs containing the VMFS may prevent the File Manager from
finding all available disks within the scan time limit.
Note: The scan time limit applies to scanning all files and sub-directories in a directory, but is usually exceeded when scanning for
disk files stored in a VMFS.
Action:
Use the directory listing utilities available in the Service Console to display the disk files stored in a particular
VMFS. For example, this command displays all the virtual disks stored in vmhba0:6:0:1:
# ls /vmfs/vmhba0:6:0:1
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:
- Log in as the root user on the service console.
- 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.
- 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>
- Raise the httpd process priority to -15:
renice -15 -p <httpd_process_ID>
- 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.
- Change the vmware-serverd process priority back to the default of zero (0).
renice 0 -p <vmware-serverd_process_ID>
- 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.
Unloading the Emulex Fibre Channel HBA Driver
ESX Server may fail to shut down cleanly when unloading the Emulex Fibre Channel HBA driver.
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 eth0 e1000) 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.
- Log into the VMware Management Interface as root.
- Click the Options tab, then click Advanced Settings.
- 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
vdf is an ESX Server-customized version of the df command. Use vdf in place of the
df command. 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.
Security Alerts for This Release
Security Updates Included in This Release
This release of ESX Server has been updated to address the following security alerts:
- CAN-2004-0885: mod_ssl Security Update
ESX Server 2.5 is not vulnerable to the security issues noted in CAN-2004-0885. This release, however,
updates the mod_ssl library to Version 2.8.20 so that CAN-2004-0885 should no longer be
identified as a vulnerability by a standard security scan. For
more details on this security vulnerability please refer to:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0885.
Security Alerts Not Applicable to This Release
The following alerts may be noted during security scans of ESX Server 2.5. These are related to system calls
not used in this release. The calls are included in third-party system libraries packaged with ESX Server 2.5
but are not actually used by the system:
- CAN-2004-0148: Root Directory Redirect During Restricted FTP Operations
Description: wu-ftpd 2.6.2 and earlier, with the restricted-gid option enabled, allows local users to bypass
access restrictions by changing the permissions to prevent access to their home directory, which causes
wu-ftpd to use the root directory instead. For
more details on this security vulnerability please refer to:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0148.
- CAN-2004-0185: Buffer Overflow with skey_challenge
Description: Buffer overflow in the skey_challenge function in ftpd.c for wu-ftp
daemon (wu-ftpd) 2.6.2 allows remote attackers to cause a denial of service and possibly execute
arbitrary code via a s/key (SKEY) request with a long name. For more details on this security vulnerability please refer to:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0185.
- CAN-2003-0466: Buffer Overflow with fb_realpath
Description: Off-by-one error in the fb_realpath() function, as derived from the realpath
function in BSD, may allow attackers to execute arbitrary code, as demonstrated in wu-ftpd 2.5.0
through 2.6.2 via commands that cause pathnames of length MAXPATHLEN+1 to trigger a buffer overflow,
including (1) STOR, (2) RETR, (3) APPE, (4) DELE, (5) MKD, (6) RMD, (7) STOU, or (8) RNTO.
For more details on this security vulnerability please refer to:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0466.
- CAN-2004-0940: Buffer Overflow with mod_include
This release of ESX Server does not use the mod_include library of system calls.
For more details on this security vulnerability please refer to:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0940.
- CAN-1999-1029: SSH Server Login Records
This release of ESX Server does not use the sshd2 SSH server.
For more details on this security vulnerability please refer to:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-1999-1029.
- CAN-2000-0999: OpenBSD SSH Server Format String Errors
This release of ESX Server does not use the OpenBSD SSH server.
For more details on this security vulnerability please refer to:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0999.
- CERT Vulnerability 464113: Remote Host Fails to Discard TCP SYN Packets
This issue relates to operating a network firewall, and using the Service Console as a
firewall is not supported by ESX Server.
For more details on this security vulnerability please refer to:
Vulnerability Note VU#464113.
- Port 1311 "Infinite Request" Attack
When using the Dell OpenManageTM 4.1 web server, a security
scan may identify the system as vulnerable to an "infinite
request" attack on port 1311. This is a false alert. For more details, see the
User Notes section of the Dell Server Administrator Version 1.9 README.
- Error apache-htpasswd-bo: Buffer Overflow with htpasswd
This is a false security alert returned during Nessus security scans of ESX Server 2.5.
For more details on this alert, please refer to:
Apache htpasswd buffer overflow.
Documentation Errata for This Release
Incorrect References to Raw Disks
In the VMware ESX Server Administration Guide, various references to raw disks
do not reflect the new functionality of raw device mappings.
Incorrect Path for vmxnet Network Driver
In Chapter 2 of the VMware ESX Server Administration Guide, the section
"Installing VMware Tools and the Network Driver in a Windows NT 4.0 Guest" includes an incorrect
path listing for the vmxnet network driver. In Step 3, the path is shown as:
D:\vmnet\winnt
The correct path is:
D:\Program files\VMware\VMware Tools\Drivers\vmxnet\winnt
This error is only in the PDF version of the Administration Guide included on the release disc.