Home > Blogs > VMware Support Insider > Category Archives: Patches

Category Archives: Patches

New ESX/ESXi Patches

A number of patches have been posted for ESX and ESXi. Details can be found in the following KB articles:

VMware ESX 4.1, Patch Release ESX410-201312401-SG: Updates VMkernel, CIM, Tools, and others (2061196)
VMware ESX 4.1, Patch Release ESX410-201312403-SG: Updates nss and nspr libraries (2061203)
VMware ESX 4.1, Patch Release ESX410-201312001 (2061209)
VMware ESXi, Patch Release ESXi410-201312001 (2061210)
VMware ESXi 4.1, Patch Release ESXi410-201312401-SG: Updates Firmware (2061205)
VMware ESXi 4.1, Patch ESXi410-201312402-BG: Updates”>VMware Tools (2061206)
VMware ESX 4.1, Patch Release ESX410-201312402-BG: Updates e1000e drivers (2061201)

Some new ESXi patches today

Some new patches for ESXI out today you might want to be aware of:

vCenter Server 5.1 Update 1a

Back on April 29th we posted an alert: ALERT: Login issue after updating to vCenter 5.1 Update 1 which detailed a scenario whereby customers might be unable to log in using the vSphere Web Client or domain username/password credentials via the vSphere Client after updating to vCenter 5.1

Tonight at 7:30pm PST, vCenter Server 5.1 Update 1 will be removed from the VMware download site and will be replaced by vCenter Server 5.1 Update 1a. The primary aim of the 5.1 U1a release is to address the regression that was identified in 5.1 U1.

Customers are urged to read the README included with the new update before they apply the update.

Details of what has and has not been fixed are provided in this KB article: http://kb.vmware.com/kb/2037410

vCenter Server issue with Oracle client resolved

Back in December, we posted the support alert: vCenter Server 5.x does not function correctly when installed with Oracle 11.2.0.3 Patch 10. The support alert was documented fully in KB article: vCenter Server 5.x does not function correctly when installed with Oracle 11.2.0.3 Patch 10 (2039874).

There is news on this alert. Oracle has since resolved the issue in the Windows Oracle Client 11.2.0.3 p16656151 (Patch 19) 64-bit, which can be downloaded today.

A couple more product upgrade notices

Here are a couple of other important items to note if you are applying updates today. We want to get this information out to our readers as quickly as possible. Please share with your colleagues:

Update vSA after upgrading to vCenter Server 5.1U1
Description: vSA 5.1.1 customers must upgrade to vSA 5.1.3 after upgrading their vCenter Server to 5.1 Update 1. For more information, see the release notes linked below.
Link: vSA Release Notes

Advisory: Upgrading to vCloud Director 5.1.x
Description: Upgrade to vCloud Director 5.1.x can affect virtual machines network connectivity due to network adapter mismatches. VMware KB article 2047922 provides tools and procedures to detect and correct network adapter type mismatches before the upgrade.
Link: Detecting and resolving network adapter type mismatches before upgrading vCloud Director to version 5.1.x (2047922)

To Patch, Perchance to Upgrade

Today we have another guest post from Tech Support Engineer Mike Bean.

'Morning everyone, I must take a moment to say thank you to people, both internally and externally, who’ve expressed support for the first column I wrote. To quote a web comic I enjoy, “we must learn, lest we stagnate”, if readers have enjoyed it as well; then I take that as a compliment!

At the risk of digressing from the “most wanted theme”, I wish to approach a new subject today. By the time you read this, ESX vSphere update 2 will be publicly available.

http://downloads.vmware.com/d/info/datacenter_downloads/vmware_vsphere_4/4

I gladly extend congratulations to all our development and QA teams the world over. I can say with complete sincerity they’re my heroes, for it is on their backs that our product is built, one feature spec and bug report at a time. Congratulations lords and ladies, hug your significant others, have a beer, and enjoy the moment. You’re our warriors!

I began my morning with a soda and a copy of the release notes, and I can safely say, it’s not light reading. Speaking as an army-ant in Global Support Services, I don’t see any issues we’ve been breathless with anticipation for, but there’s also far too many things being addressed to engage in any sweeping generalization.

http://www.vmware.com/support/vsphere4/doc/vsp_esx40_u2_rel_notes.html

In the course of my time here, I’ve often been asked the eternal question “should I get the patch?” I’m never quite sure how to answer this question, but it’s honestly one worth asking. So it’s worth taking a moment to examine.

Asking a software company if you should apply the patch is a little like asking a lawyer if you should sue; let’s face it, we have a slight bias. On one hand, if we didn’t think our customers would benefit, we wouldn’t have released the patch in the first place. On the other hand, many of my customers are system admins, and I’ve walked a mile in their shoes. In that sense, I’m well aware that they don’t have the liberty of applying patches/FW flashes whenever any number of numerous vendors they do business with, releases the latest update. My college economics classes would’ve called it “opportunity cost”. Downtimes must be scheduled, approvals must be obtained, benefits assessed. It is precisely because I have experienced both the software development point of view, and the system administration point of view, that I’m well aware that many of our customers may not have had problems. Risk is relative, myself and my co-workers routinely speak to customers who’ve literally ran for years without issues. Why then, upgrade?

Typically, when a customer asks me that question on the phone, I often end up trying to explain that I can’t really answer that question. It’s the natural course of software development that a changing code base means a changing landscape. Old problems are solved, and new ones arise, and I won’t imply to the contrary. However, that should not be interpreted as carte blanche to never patch. Risk may be relative, but as available security and stability fixes accumulate, so does risk, and so does benefit.

It’s a matter of risk assessment, as a GSS TSE (technical support engineer) it’s my responsibility to try and help present the facts and the options, but ultimately, the final decision always belongs to the customer. Only they know their networks, and basically, only they can realistically decide when the benefits of patching will exceed the costs. Inevitably, the only safe policy is one of shared information (informed consent); In that spirit, I encourage most everyone I speak to familiarize themselves with the available resources, both in documents and communities. Examine the facts for yourself, and let the update speak for itself.

In closing, I would briefly highlight at least one real case from memory. I spoke with a customer some weeks ago who’d been having substantial issues with hangs on his cluster of Dell 2900s. I sincerely hope he’s watching update 2’s contents, very carefully!

http://www.vmware.com/support/vsphere4/doc/vsp_esx40_u2_rel_notes.html#resolvedissues

VMware ESX might fail to boot on Dell 2900 servers
If your Dell 2900 server has a version of BIOS earlier than 2.1.1, ESX VMkernel might stop responding while booting. This is due to a bug in the Dell BIOS, which is fixed in BIOS version 2.1.1.

Workaround: Upgrade BIOS to the version 2.1.1 or later.

You spoke, and we were listening! Till next time!

KB Highlight: Patch now available for the RAID Cache issue affecting ESX/ESXi 4.0 systems

Recently we told you about an issue where the RAID controller does not clear the cache during shutdown. A patch is now available to resolve this problem.

If you have ESX/ESXi 4.0 systems with RAID controllers using aacraid, megaraid2, and megaraid_sas drivers with attached local storage, then check out this article System does not clear RAID controller cache during shutdown (1012794) for details and symptoms.

For installation instructions for the patch, check out VMware ESXi 4.0, Patch ESXi400-200907401-BG or VMware ESX 4.0, Patch ESX400-200907401-BG.

ESX Patches May 28

A new bunch of patches for ESX 3.5 and 3.0.x have been posted this week.  If you’re still in the old Virtual Infrastructure 3 world, you might want to look in to the latest patches as they contain security and critical updates.

ESX 3.5.0 Classic

Patch # Summary KB
ESX350-200905401-BG VM Shutdown & Host Reboot  KB:1010957
ESX350-200905402-BG VM Shutdown & No Host Reboot  KB:1010958
ESX350-200905403-BG VM Shutdown & Host Reboot  KB:1010960
ESX350-200905404-BG No VM Shutdown & No Host KB:1010961
ESX350-200905405-BG VM Shutdown & Host Reboot KB:1010963
ESX350-200905401-SG VM Shutdown & Host Reboot  

ESXi 3.5.0

Patch # Summary KB
ESXe350-200905401-I-BG VM Shutdown &  Host Reboot KB:1010964

Patch Download and Installation

See the VMware Update Manager Administration Guide for instructions on using Update Manager to download and install patches to automatically update ESX Server 3.5 hosts.

To update ESX Server 3.5 hosts when not using Update Manager, download the most recent patch bundle from http://www.vmware.com/download/vi/vi3_patches_35.html and install the bundle using esxupdate from the command line of the host. For more information, see the ESX Server 3 Patch Management Guide.