Release Date: June 24, 2010
|Product Versions||ESX 3.5|
|Virtual Machine Migration or Reboot Required||Yes|
|Host Reboot Required||Yes|
|PRs Fixed||528563, 413019, 525323, 507541, 482714, 458631, 451013, 371393, 522536, 403421, 528158, 464044, 491562|
|Related CVE Numbers||CVE-2008-5029, CVE-2008-5300, CVE-2009-1337, CVE-2009-1385, CVE-2009-1895, CVE-2009-2848, CVE-2009-3002, CVE-2009-3547, CVE-2009-2698, and CVE-2009-2692|
Summaries and Symptoms
The service console kernel package is updated to kernel-2.4.21-63. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2008-5029, CVE-2008-5300, CVE-2009-1337, CVE-2009-1385, CVE-2009-1895,CVE-2009-2848, CVE-2009-3002, and CVE-2009-3547 to the security issues fixed in kernel-2.4.21-63.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2009-2698, CVE-2009-2692to the security issues fixed in kernel-2.4.21-60.
This patch also fixes the following issues:
- Removal of all snapshots from a virtual machine with the Delete All option can use large amounts of disk space.
When you use the Delete All option in Snapshot Manager, the snapshot farthest from the base disk is committed to its parent, causing the parent snapshot to grow. When that commit is complete, that snapshot is removed and the process starts over on the newly updated snapshot to its parent. This continues until every snapshot has been committed. This method can be relatively slow because data farthest from the base disk might be copied several times. More importantly, this method can aggressively use disk space if the snapshots are large, which is especially problematic if a limited amount of space is available on the datastore. The space issue is troublesome especially if you choose to delete snapshots explicitly to free up storage.
This issue is resolved in this patch. The order of snapshot consolidation has been modified to start with the snapshot closest to the base disk instead of the farthest. The end result is that copying data repeatedly is avoided.
- When you upgrade VMware Tools using the VirtualCenter Server, the VI Client, or Windows CLI with theREBOOT=ReallySuppress or REBOOT=R parameter, the parameters do not stop the virtual machines from rebooting.
After installing this patch, you can run the following command at the command prompt in the guest operating system to stop the virtual machines from rebooting: VMwareToolsUpgrader.exe -p "/s /v\"/qn REBOOT=R\"". You can stop the rebooting only using the REBOOT=R parameter. This parameter is available only after you install this patch, and can be used for further upgrading of VMware Tools.
- ESX hosts might stop responding when interrupts are shared between VMkernel and service console.
The following symptoms might be visible:
- Network pings to the ESX hosts might fail.
- Baseboard management controllers (BMC) such as HP integrated Lights-Out (iLO) console might appear to be in a non responsive state.
- CPU utilization of vmware-user process might reach 100% on virtual machines running Linux guest operating systems. This issue occurs when you start a Linux virtual machine that is running on a system in a locale other than English, log in to a guest operating system console (X Window), and log out of the console.
- When you register virtual machines using a corrupted .vmxf file, the virtual machines move into an invalid state in the VI Client. An NFS outage might corrupt the .vmxf file.
The virtual machines move into an invalid state.
- ESX might fail and display a purple screen due to high memory usage. This issue occurs when hundreds of cimserver or other processes are forked during some peculiar error-handling conditions. The following error message might appear in the VMware CIM log:
Exception: NOT_IMPLEMENTED /build/mts/release/bora-176894/bora/vmkernel/include/public/cosVmnixSyscall.h:411
- ESX host might stop responding when 15 or more virtual CD or DVD drives are attached.
Each time such a drive from remote management devices such as Dell DRAC, HP iLO, IBM ASM/RSA/cKVM, or Sun ILO is disconnected and reconnected, the ESX host might detect it as a new device. These are presented
as USB devices. When 15 or more such virtual devices are accumulated, the ESX host might stop responding. This issue might also occur due to repeated attaching and detaching of a physical USB CD or DVD drive.
The following symptoms might occur without this patch:
- The /var/log/messages log file might display many similar messages about USB storage devices being disconnected and appearance of new devices.
Jul 10 10:46:18 v-6048a-x6450c-scaa kernel: Vendor: AMI Model: Virtual CDROM Rev: 1.00
Jul 10 10:46:18 v-6048a-x6450c-scaa kernel: Type: CD-ROM ANSI SCSI revision: 02
Jul 10 10:46:18 v-6048a-x6450c-scaa kernel: SR 58: scsi-1 drive
Jul 10 10:46:18 v-6048a-x6450c-scaa kernel: sr 6:0:119:0: Attached scsi generic sg120 type
Jul 10 10:47:48 v-6048a-x6450c-scaa vobd: Jul 10 10:47:48.217: 23253452137us: [vprob.storage.connectivity.lost] Lost connectivity to storage device mpx.vmhba92:C0:T0:L1. Path vmhba92:C0:T0:L1 is down. Affected datastores: Unknown.
Jul 10 10:51:51 v-6048a-x6450c-scaa kernel: Vendor: AMI Model: Virtual CDROM Rev: 1.00
Jul 10 10:51:51 v-6048a-x6450c-scaa kernel: Type: CD-ROM ANSI SCSI revision: 02
Jul 10 10:51:51 v-6048a-x6450c-scaa kernel: SR 59: scsi-1 drive
Jul 10 10:51:51 v-6048a-x6450c-scaa kernel: sr 6:0:121:0: Attached scsi generic sg122 type 5
- The /proc/sys/dev/cdrom/info file displays an unexpectedly large number of devices.
- You might see a large number of CD-ROM device nodes, for example /dev/scd12, /dev/sr12.
- A journal might be aborted in the middle of a truncate or restart operation, which can cause a panic (or OOPS) in the ESX service console.
- VMotion fails between hosts using Intel Xeon 56xx or 36xx series processors to hosts using specific Intel processors.
- Users are unable to create mirrored disks in a virtual machine running Windows Server 2008 R2 operating system. When you perform software mirroring, after you format the mirrored volume, the volume is marked as Failed Redundancy.
- Installation of VMware Tools followed by snapshot creation causes virtual machines to get into an invalid state.
- The hostd logs are filled with NotAuthenticated error messages when the ESX host is powered on.
None beyond the required patch bundles and reboot information listed in the table, above.
Patch Download and Installation
Note: All virtual machines on the ESX host must be either shut down or migrated using VMotion before applying the patch. A reboot of the ESX host is required after applying this patch.
Based on VMware KB 1022899