VMware announced some new patches for 4.1 and other products today. One is listed as critical. it is recomended that you upgrade soon as possible. Links are below:
There is also a Security Patch with the following issues resolved:
This patch resolves multiple security issues by updating the likewisekrb5, likewiseopenldap, likewiseopen, and pamkrb5 packages. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2009-0844, CVE-2009-0845, CVE-2009-0846, CVE-2009-4212, and CVE-2010-1321 to these issues.
In addition, this patch fixes the following issues:
- When an user who is a member of more than 32 groups attempts to log into an ESXi host by using KVM, any one of the following issues might occur:
- ESXi host restarts
- ESXi host becomes unresponsive
Note: With this patch, a user who is a member of more than 128 groups can access the console, but loses any group information beyond the 128th group.
- The Health Status tab shows false alerts and zero readings for voltage and temperature sensors when you connect a vSphere Client to the vCenter Server that manages ESXi hosts running on Unisys ES7000 Model 7600R Enterprise Server or NEC Express5800/A1040.
- When a storage controller fails, an ESXi software iSCSI initiator instance with default settings takes about 45 seconds to detect the problem and inform the ESXi storage stack to initiate storage failover. For some array models, such as those that use LSI controllers, this problem results in storage failover taking more than 60 seconds to complete after the I/O is sent from the virtual machines. This can cause I/O errors to be reported by applications and the guest operating system running in the virtual machine. This patch resolves this issue.
After installing this patch, you can configure the parameters Noop Interval and Noop Timeout by using the vCenter Server. These parameters enable you to reduce the timeout value based on the storage arrays, so that the software iSCSI initiator can detect changes in the path state faster and initiate storage failovers. The default values of the parameters forNoop Interval is 40 and Noop Timeout is 10.
- Virtual machines are suspended and multiple storage alerts are raised on multiple ESXi hosts resulting in an all-paths-down state. The VMkernel log file contains the following message:
NMP: nmp_DeviceAttemptFailover: Retry world failover device. "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" - failed to issue command due to Not found (APD), try again...
This issue occurs because ESXi does not accept new paths that are exported from EMC Symmetrix Storage after an ESXi host boot-up or an all-paths-down state.
- The esxcfg-volume utility might fail to mount VMFS volumes with snapshots, and displays an error message similar to the following:
Error: Unable to resignature this VMFS3 volume due to duplicate extents found
If you dynamically add capacity from the storage device to the VMFS datastore and perform a VMFS rescan operation, the VFMS volumes on ESXi hosts might not mount under /vmfs/volumes/ when you use the esxcfg-volume utility. This issue might occur due to dynamic expansion of snapshot volumes from storage having multiple extents. With this patch, ESXi improves handling for multiple partitions or devices in VMFS volumes.
- The Network window in the vSphere 4.1 esxtop tool incorrectly reports a large number of dropped receive-packets (%DRPRX) for virtual machines that are using the E1000 virtual NIC with multicast traffic.
- After an ESXi host is upgraded to ESXi 4.1 or after ESXi 4.1 is installed, you might experience the following symptoms:
- vSphere client might display incorrect values for the number of Processor sockets and cores per socket available in the ESXi system. For example, for a ESXi system that has 2 processor sockets and 6 cores per socket, the vSphere Client might display that the ESXi system has 4 processor sockets and 3 cores per socket.
- Some ESXi 4.1 systems might use double the number of licenses required.
- Some ESX/ESXi hosts might lose their license.
- A potential race condition between the destroying slowpath agent function and the socket wakeup callback function might cause an ESXi host to stop responding and displays a purple screen.
- If VMware Tools of version ESXi 3.5 or later is installed on Windows virtual machines that are configured with the automatic VMware Tools upgrade option, automatic upgrade to ESXi 4.1 VMware tools on these virtual machines might fail with an error message similar to the following:
Error upgrading VMware Tools.
- If you start a Microsoft Windows Server 2003 32-bit virtual machine with /3GB switch defined in the boot.ini file on VMware ESXi 4.1, you might see the following symptoms:
- Read or Write memory errors occur in the guest operating system.
- A Remote Procedure Call (RPC) error is reported and the virtual machine is forced to reboot often.
- A stop code of type 0x000000F4 occurs.
- Microsoft .NET or Java applications might fail with memory errors.
- The Microsoft Windows Event log might contain error messages similar to the following:
Event Type: Error
Event Source: .NET Runtime
Event Category: None
Description:.NET Runtime version 2.0.50727.3615 - Fatal Execution Engine Error (7A0979AE) (80131506)
- For ESXi running on BULL servers, vSphere Client displays the names of the Processor and Power sensors starting with 96 on the Configuration tab. For example, Processor 96 or PowerSupply 97.
With this patch, the Processor and Power sensors names are displayed starting with Processor 0 or PowerSupply 1.
If passwords of more than eight characters are set for ESXi 4.1 system users, the set password is truncated to eight characters, and the system evaluates only the first 8 characters of the password submitted for authentication.
Note: To implement this fix, reset the password of the existing ESXi 4.1 system users after applying the patch.
Leave a Reply