VM /ETC

Archive for the ‘patch’ Category

A new patch for VMware ESX 3.5 Update 3 was released last week that fixes the previously reported iSCSI and FC Alert – “Queue for device has been blocked” issue. The fix was part of a bundle of patches released for ESX 3.5, ESXi 3.5 and ESX 3.0.x products.

Duncan’s summary post over at yellow-bricks.com pointed me to the new VMware KB article specific to the patch with the I/O alert fix: VMware ESX 3.5, Patch ESX350-200901401-SG: Updates VMkernel, VMX, and hostd

Upon reading the KB article I noticed that the VI Client NTP configuration issue I have posted about, and continue to run into, has also been fixed.

Read VMware’s KB for all “the other issues” corrected along with some information about applying the patches with or without Update Manager.

Did you take the time to plan for VMware Update Manager (VUM) when designing your virtual infrastructure architecture? Planning focus is usually on VirtualCenter (VC) server’s requirements, but then, in my experience, Update Manager and it’s default local SQL 2005 Express database seem to be added on the VC server simply because the installer is prompted about VUM during the VC setup routine. This scenario can create a poor performing VUM implementation.

Recently on the VMware Performance Team’s VROOM blog, John Liang’s post titled VMware Update Manager Performance and Best Practices Paper Posted announced a new whitepaper that should be a must read for any virtual infrastructure administrator preparing to use (or already using) VUM. The .pdf is a 14 page discussion on the topics that impact VUM such as performance, networking, resource consumption, and even virus scanning.

I find a few of these recommendations interesting, and the whitepaper leaves me wondering how common using VUM for virtual machine OS patching really is. I’ve created two informal polls, so please take a second to complete them and maybe we can get a quick gauge on how VUM is commonly implemented.

[poll id="2"][poll id="3"]

The whitepaper is a quick, informative read that I strongly encourage, but the following list of best practices was copied from the whitepaper’s Conclusion section.
Read the rest of this entry »

Being that it is the end of the week and I have fallen a day or so behind in keeping up with the VMware updates for the August 12 time bomb bug, I decided that I would post the remaining emails I received from VMware. I’m also including an update from John Troyer from the VMTN Blog providing some clarity on version number information differences between the install media and the express patched ESX/ESXi 3.5 versions. Read the rest of this entry »

I just received the third VMware email customer update about the August 12 time bomb bug. Unfortunately, this email informs customers that the effort to find a resolution where VM reboots could be avoided has not produced a reliable process. The email does indicate that the express patches are working properly and are compatible with VMware Update Manager. Also, The previously set deadline of 6 PM PST today (AUG 13) for the download availability of the corrected ESX/ESXi update 2 install media is still on schedule.

Here’s the body of the entire email as I received it: Read the rest of this entry »

Based on the email I received from VMware at 1:14 am EST last night, the express patches for the ESX 3.5 and ESXi 3.5 Update 2 product expiration bug have been released and are available for download. This availability would have been 10:14 pm PST and slightly later than the 9:00 pm promised deadline. This is still impressive customer response in my opinion as the ESX team is no doubt working around the clock to provide a fix around the world. VMware’s next deadline is 6 pm PST tonight (August 13) to provide the reissued upgrade media.

There are now 3 KB articles related to this bug:

• Fix of virtual machine power on failure issue, refer to KB 1006716
• For VI 3.5, refer to KB 1006721 for deployment consideration and instruction
• For VI3.5i, refer to KB 1006670 for deployment consideration and instruction

The whole email is copied at the end of this post, but here is the important information from the email about the express patches:

We have released the express patches for the product expiration issue. Please
go to http://www.vmware.com/go/esxexpresspatches for more information.

1. What do the express patches do?

There are two express patches: one for ESX 3.5 Update 2 and one for ESXi 3.5
Update 2. They are specifically targeted for customers who have installed or
fully upgraded to ESX/ESXi 3.5 Update 2 or who have applied the
ESX350-200806201-UG patch to ESX/ESXi 3.5 or ESX/ESX 3.5 Update 1 hosts. For
customers who haven’t done either, these express patches should not be applied.

To be noted is that these patches have been validated to work with esxupdate.
However, testing with the VMware Update Manager is still under way. In
subsequent communications, we will provide confirmation whether the patches work
with VMware Update Manger or if a re-spin is required.

We are currently testing an option to apply the patch without requiring
VMotion or VM power-off and re-power-on at the point of patch application. To
immediately refresh vmx on the VM, one can VMotion off running VMs, apply the
patches and VMotion the VMs back. If VMotion capability is not available, VMs
can be powered off before the patches are applied and powered back on
afterwards.

The following is the email I received from VMware in it’s entirety. Read the rest of this entry »

I just received word that the following email is being sent (or will be sent) to all ESX 3.5 and ESXi 3.5 customers likely to be impacted by the Aug 12 time bomb BUG. I assume the 6:00 pm deadline is PST as VMware’s headquarters is in Palo Alto, California?

Dear VMware Customers,

Please find the latest update about the product expiration issue. From this point on, we’ll provide an update every two hours. Thanks.

Problem:

An issue has been discovered by many VMware customers and partners with ESX/ESXi 3.5 Update 2 where Virtual Machines fail to power on or VMotion successfully. This problem began to occur on August 12, 2008 for customers that had upgraded to ESX 3.5 Update 2. The problem is caused by a build timeout that was mistakenly left enabled for the release build.

Affected Products:

- VMware ESX 3.5 Update 2 & ESXi 3.5 Update 2

- Reports of problems with ESX 3.5 U1 with the following 3.5 Update 2 patch applied.

1. ESX350-200806201-UG

- No other VMware products are affected.

What has been done?

Read the rest of this entry »

New Patches have been released for ESX 3.5 / 3i, ESX 3.02, and ESX 3.01. Information from the email notifications I received are copied in this post. Looks like monthly patching has become a reality for VMware. That’s the ultimate proof of success, I guess. If it’s a popular product the chances of it being exploited are increased exponentially. Make sure your Update Manager server is working properly …..

Read the rest of this entry »