KB with a description of what happened: http://kb.vmware.com/kb/1006716
ESX Express Patches: http://www.vmware.com/go/esxexpresspatches
Let's close down the other thread, as it's getting really long and hard to navigate.
Letter from Paul Maritz: http://communities.vmware.com/thread/162713. Please post non-technical commentary here.
Please post further technical commentary about the patches in this thread.
Thanks. Rest assured that many people inside VMware are reading your feedback and experiences here.
Yes it certainly does show 2 releases of U2 when performing a query. The update took about 10 minutes. A reboot of the host is required to upgrade from this build (110181) to this build (110268).
I am seeing the same results with UM, but when I try to remediate the systems it tells me that they are already up-to-date and will not apply any patches. Also, UM says that I am not compliant on any of my systems that have the old U2 update and the Time Bomb patch.
I have not tried any pre-u2 hosts as of yet.
As for hosts with u2 and the timebomb patch, I've been remediating to the new builds (just leaving everything selected) and it has been working fine.
Note the VMware tools build is new and also installed fine for me, although having the original u2 build of VMware tools does not appear to trigger any 'out of date' notification so unless I hear/see otherwise, I'm not redoing all the tools upgrades....
We applied for the Alternative Install Procedure (received an email about this). This afternoon we received the download link and tried the install in our testenvironment. This patch contains an install script and some binaries. Your host will NOT be put in maintenance and your VM's DON'T need to be shutdown.
After applying the patch I could not find it with "vmware -v" (still 103908) or "esxupdate query" that was a bit scary but vmotion DID work so I could put hosts in maintenance (applied patch on entire farm) and am now busy patching the entire farm the 'regular' way to build 110268.
I had posted earlier about issues going back to update U1 boxes using Update Manager. This issue was resolved by the slew of patch releases on 08/13. I can now update U1 (and prior versions) without error (using the default "Critical Host Updates" and "Non-Critical Host Updates" baselines). This results in a server being updated to 3.5.0, 110268. However, now, using the default provided baselines ("Critical Host Updates" and "Non-criticial Host Updates"), I can no longer patch any box that is 3.5.0, 103908 (the time-bombed version of U2). Installation fails on ESX350-200802301-BG stating that "A newer version of the patch is already installed".
If I create a separate baseline that only includes patches released 08/12/08 - 08/13/08... removing the Time-Bomb patch (ESX350-20086812-BG), but including ESX350-Update-02, then I can patch U2 Servers that have not yet had the "Time-Bomb patch (ESX350-20086812-BG) installed. These servers wind up as version 3.5.0, 110181
If I attempt to install all patches released from 08/12/08 - 08/13/08 onto U2 Servers (3.5.0. 103908) that have already had the "Time-Bomb" fix (ESX350-20086812-BG), then installation fails on ESX350-200806812-BG with an error that "Installation failed - higher version of patch already installed".
A quick check reveals that, following the bevy of patches released on 08/13/08, if you use the default baselines, they attempt to reinstall stuff as old as 03/04/08.... even though these patches are already installed. In addition, all servers now show "Not Compliant" in update manager for all of these old patches, dating back to 03/04/08.... even though these patches are already installed.
So it looks the like the "Critical Host Updates" and "Non-Critical Host Updates" default updates, if unedited, are no longer applicable, functional, or usable for any U2 version servers... meaning you must have a seperate "All Update" patch list for Pre-U2 servers and U2-Post servers. Which complicates matters if you have a mix of servers within a cluster or data center. In a multi-DataCenter, Multi-Cluster, hundred+ host environment, this is somewhat of an annoyance. It also leaves us without a single query capability to determine compliance of our servers.
I have not read through the remainder of the thread or KB articles thus far today so I am unsure if there is a repair in work but I am finding it difficult to get my servers at the same revision levels (3.5.0, 110286). The results described above are consistent and reproducible in my environment.
EDIT: Correction - I have managed to get U2 version 3.5.0, 103908 updated to version 110286, U2 version 110181 upgraded to 110286, and everything prior to 103908 upgraded to 110286. It's not as consistent as I would like and it is requiring 2 baselines in my environment to make this occur.
Dear VMware Customers,
In addition to the express patch and the re-issued ESX/ESXi 3.5 Update 2 release, we now have an alternative installation process for customers who haven't applied either to hosts that were affected by the product expiration issue.
Below are the details we list at http://www.vmware.com/landing_pages/esxexpresspatches.html:
*Known VMware ESX 3.5 Update 2 Express Patch Installation Challenges
The following message is applicable ONLY for customers who had installed the impacted release of ESX 3.5 Update 2 (build number 103908), but not yet applied the express patch.
We are aware that you may encounter the following challenges installing the express patches needed to correct the problem:
Internal change control procedures
No available server to VMotion running VM's onto
Unable to schedule a maintenance window
If you experience one of the challenges listed above, please contact your support provider and indicate you need assistance with the U2 Alternative Install Process (U2 AIP). The support team can assist customers with this alternative installation procedure.
The VMware ESX Product Team
All this patch mayhem has really put a big dent in my trust for VMWare. I've now spent something like 20 hours just trying to patch our four machines. Update Manager behaviour is random at best. I expect the next VI update to be much more professional or we will actively start to look for alternatives.
Martin, I totally agree, however, It is highly recommended that if one patch worked, you should wait a while for a much more stable patch later. Also I HIGHLY recommend using the "Good ol fashioned" commandline patch at the console. UM seems to be having some issues on updates. Basically too many incremental patches going on. If one patch fixed the expiry bug then stick with it till a solid patch is released. This goes for everyone else out there. There's really no need to patch every minor version of the expiry bug. If the first patch worked for you and you can VMotion, Storage Vmotion and DRS is working, hell, take the rest of the day off and have a dang BEER!
The problem was that while I was patching, the UM downloaded the "new" upgrade 2, so half of my servers got the "bugged" u2. Also the update manager worked so bad that it took several tries and reboots of the ESX hosts to get the update going.
Today HA stopped working everywhere, so I've spent the morning putting every machine in maintenance mode, putting it in another cluster, leaving maintenance mode, entering maintenance mode and putting it back in the original cluster. It seems to work now.
Also: When migrating the virtual center server with DRS during this time, Virtual Center promptly bugged and I had to restart the service. Solid...