This patch resolves the following issues :

• After upgrading Cisco Nexus 1000V VSM to the latest version, you might not be able to patch the kernel of ESX hosts attached to the vDS (KB 1015717)Upgrading Cisco Nexus 1000V VSM to the latest version upgrades the Cisco Virtual Ethernet Module (VEM) on ESX hosts attached to the vDS. Subsequently, from the same vSphere Client instance, you might not be able to use a host patch baseline to apply patches to the ESX vmkernel64 or ESXi firmware of hosts attached to the vDS. Applying patches to ESX vmkernel64 or ESXi firmware requires that you include the compatible Cisco Nexus 1000V VEM patch in the baseline. However, this patch might not be available for selection in the Update Manager New Baseline wizard or in the Update Manager patch repository.
• Upgrade of Cisco Nexus 1000V version 4.0(4)SV1(1) to version 4.0(4)SV1(2) with Update Manager might fail for hosts with certain patch levels (KB 1017069)If you are using Cisco Nexus 1000V version 4.0(4)SV1(1), and the ESX patch bulletins ESX400-200912401-BG or ESXi400-200912401-BG are installed on the host, you might not be able to upgrade to Cisco Nexus 1000V version 4.0(4)SV1(2).
• Scanning of hosts in a cluster and staging of patches to hosts in a cluster might take a long time to finishThe scanning and staging operations of hosts in a cluster run sequentially. If a cluster contains a lot of hosts, scanning and staging patches might take a long time to be completed. Scanning and staging of hosts in a cluster run concurrently on all of the selected hosts in the cluster.

For details regarding these new fixes, please refer to the release notes.

VMware vCenter Update Manager 4.0 Update 1 Patch 1 is available for download.

VMware vCenter Update Manager 4.0 Update 1 is required for installation of this patch.

Source

Fixes an issue where a guest operating system shows high memory usage on Nehalem based systems, which might trigger memory alarms in vCenter. These alarms are false positives and are triggered only when large pages are used. This fix selectively inhibits the promotion of large page regions with sampled small page files. This provides a specific estimate instead of assuming a large page is active when one small page within it is active.

BEFORE INSTALLING THIS PATCH: If you have set Mem.AllocGuestLargePage to 0 to workaround the high memory usage issue detailed in the Summaries and Symptoms section, undo the workaround by setting Mem.AllocGuestLargePage to 1.

Six patches have been released today but this fix was probably the one that people talk about the most that’s why I wanted to make everyone aware of it! Download the patches here.

Site Recovery Manager 1.0 Update 1 Patch 4
File size: 7.9 MB
File type: .msi

Here are the most important fixes:

• a problem that could cause a recovery plan to fail and log the message
  Panic: Assert Failed: “_pausing” @ d:/build/ob/bora-172907/santorini/src/recovery/secondary/recoveryTaskBase.cpp:328
• a problem that caused the SRM SOAP API method getFinalStatus() to write all XML output on a single line
• full session keys are no longer logged (partial keys are used in the log instead)
• a problem that could cause SRM to crash during a test recovery and log the message
  Exception: Assert Failed: “!IsNull()” @ d:/build/ob/bora-128004/srm101-stage/santorini/public\common/typedMoRef.h:168
• a problem that could cause a recovery plan test to fail to create test bubble network when recovering virtual machines that had certain types of virtual NICs
• a problem that could cause incorrect virtual machine start-up order on recovery hosts that enable DRS
• a problem that could cause the SRM server to crash while testing a recovery plan
• a problem that could cause SRM to fail and log a “Cannot execute scripts” error when customizing Windows virtual machines on ESX 3.5 U1 hosts.
• support for customizing Windows 2008 has been added
• a problem that could prevent network settings from being updated during test recovery for guests other than Windows 2003 Std 32-bit
• a problem that prevents protected virtual machines from following recommended Distributed Resource Scheduler (DRS) settings when recovering to more than one DRS cluster.
• a problem observed at sites that support more than seven ESX hosts. If you refresh inventory mappings when connected to such a site, the display becomes unresponsive for up to ten minutes.
• a problem that could prevent SRM from computing LUN consistency groups correctly when one or more of the LUNs in the consistency group did not host any virtual machines.
• a problem that could cause the client user interface to become unresponsive when creating protection groups with over 300 members
• several problems that could cause SRM to log an error rmessage vim.fault.AlreadyExists when recomputing datastore groups
• a problem that could cause SRM to log an Assert Failed: “ok” @ src/san/consistencyGroupValidator.cpp:64 error when two different datastores match a single replicated device returned by the SRA
• a problem that could cause SRM to remove static iSCSI targets with non-test LUNs during test recovery
• several problems that degrade the performance of inventory mapping

I’m not going to reiterate everything that has been reported in this VMTN Topic about the problem, but what I would like to mention is that a patch will be released soon to fix the incorrect alarms:

Several people have, understandably, asked about when this issue will be fixed. We are on track to resolving the problem in Patch 2, which is expected in mid to late September.

In the meantime, disabling large page usage as a temporary work-around is probably the best approach, but I would like to reiterate that this causes a measurable loss of performance. So once the patch becomes available, it is a good idea to go back and reenable large pages.

Also a small clarification. Someone asked if the temporary work-around would be “free” (i.e., have no performance penalty) for Win2k3 x64 which doesn’t enable large pages by default. While this may seem plausible, it is however not the case. When running a virtual machine, there are two levels of memory mapping in use: from guest linear to guest physical address and from guest physical to machine address. Large pages provide benefits at each of these levels. A guest that doesn’t enable large pages in the first level mapping, will still get performance improvements from large pages if they can be used for the second level mapping. (And, unsurprisingly, large pages provide the biggest benefits when both mappings are done with large pages.) You can read more about this in the “Memory and MMU Virtualization” section of this document:

http://www.vmware.com/resources/techresources/10036

Thanks,
Ole

Mid / Late september may sound to vague for some and that’s probably why Ole reported the following yesterday:

The problem will be fixed in Patch 02, which we currently expect to be available approximately September 30.

Thanks,
Ole

In total 11 new patches (9 for ESX and two for ESXi) are up for download. Make sure to read the accompanied KB articles first and of course test the patches before implementing!

Have fun,

Site Recovery Manager 1.0 Update 1 Patch 3 Latest Release Version: 1.0.1.2587 | 04/09/09 | 154949

This patch corrects the following problems:

• a problem that prevents protected virtual machines from following recommended Distributed Resource Scheduler (DRS) settings when recovering to more than one DRS cluster.
• a problem observed at sites that support more than seven ESX hosts. If you refresh inventory mappings when connected to such a site, the display becomes unresponsive for up to ten minutes.
• a problem that could prevent SRM from computing LUN consistency groups correctly when one or more of the LUNs in the consistency group did not host any virtual machines.
• a problem that could cause the client user interface to become unresponsive when creating protection groups with over 300 members several problems that could cause SRM to log an error rmessage vim.fault.AlreadyExists when recomputing datastore groups.
• a problem that could cause SRM to log an Assert Failed: “ok” @ src/san/consistencyGroupValidator.cpp:64 error when two different datastores match a single replicated device returned by the SRA.
• a problem that could cause SRM to remove static iSCSI targets with non-test LUNs during test recovery several problems that degrade the performance of inventory mapping.

VMware ESX 3.5, Patch ESX350-200904201-SG: Updates VMX RPM
Issues fixed in this patch (and their relevant symptoms, if applicable) include:

• A critical vulnerability in the virtual machine display function might allow a guest operating system to run code on the host. The Common Vulnerabilities and Exposures Project (cve.mitre.org) has assigned the name CVE-2009-1244 to this issue.

Fixing your broken installation is fairly easy:

To use this patch, download it from the attachment, gunzip it, then go to your /usr/lib/vmware/modules/source directory. Untar all of the files. Apply the patch with “patch -p1″. After the patch has applied, re-tar all the files. Then, run “vmware-modconfig –console –install-all” again, under Linux 2.6.29, and it should now work.

Go to the VMTN Forums and download the patch if you are having trouble getting the VMware Workstation kernel modules compiled correctly!

1. ESX350-200903412-BG – PATCH – KB 1009232 – General
   Updates Kernel Source and VMNIX
2. ESX350-200903411-BG – PATCH – KB 1009231 – Critical
   Updates the bnx2x Driver for Broadcom

Download them now!