ESX 3.5U2 Patch experiences?

[admin]

Just posted:

• 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.

[Intelligen]

When the patch was released last night (were CST) I patched our DR host host's. It took awhile for them since they are across the WAN with a 35 MB connection and bringing down the patch was a bit slow. Once the install initiated it wasn't too bad.

Same with our main DC, 4 hosts but these went faster since they are on local LAN so pulling down the 100 MB patch was nothing.

I ended up patching a total of 8 ESX hosts with no problems. Went very smooth. Glad VMware came through with a patch so quickly.

[smithers0105]

Patched our solitary 3.5U2 server (one of a two server test cluster, the other member still being on 3.0.2 - our other 4 production servers are still 3.0.2 also). I've never patched any of the servers since our 3.0.2 environment was installed a year ago, so my first time to use esxupdate.

Used pscp to copy the patch over to the ESX 3.5U2 box, then 'esxupdate update'. All appeared to install OK, with the 110181 build displayed in the VI Client. However, still comes up with the error message when clicking on Licensed Features (see attached image) or when migrating a VM from the 3.0.2 box and trying to start it up. esxupdate -l query says the patch is installed. Re-running esxupdate update says it is already installed.

In case it helps, I actually only ran the 3.0.2 -> 3.5U2 upgrade (via the CD) yesterday (Aug 12) so the box was broken on first startup and so was not a working 3.5U2 server that I installed that existed before August 12, I had never even taken it out of maintenance mode until this morning after I installed the patch (was getting Operation Timed out errors doing the exit maint mode). Restarted the ESX server and the VC several times, no joy (I have not restarted the 3.0.2 server). I also tried changing the time back to 8th August with the same problem. Now, I had checked all the tabs for the when it was 3.0.2 just before running the 3.5U2 upgrade, so I KNOW that the licensing was definately working.

It's a test server but we still have VMs used by end-users, all of which are just about squeezing in to the remaining 3.0.2 cluster member.

Any ideas how I can get out of this one?

[sjourney]

yes Baseline is dynamic, also created new baseline with just that patch. still compliant...

UM downloaded patches last night, did scan on hosts this AM, UM still says they are Compliant?? What gives? I know I'm effected. Have not had any problems with UM before...Is your baseline dynamic? If not you'll have to change the baseline to include the patch.

[smithers0105]

Umm, forget my previous question about why has my patched 3.5U2 test server still got the problem, I have since found that the license server name (which was an FQDN to the license server located in our production AD domain) did not resolve in our test domain DNS server. Quite why it was missing is strange, quite why the 2nd test server (3.0.2) running against the same license server did not complain, I do not know (maybe 3.0.2 only checked for the license server during the initial install/configuration?) Added the FQDN into our test DNS and Edited the license server info and hit OK, all licensing popped up again.

Anyway, a schoolboy error, obviously Sorry to waste people's time!

[kcvman]

One host in cluster was upgraded to U2. Ran the timebomb patch ESX350-200806812-BG on it. Rebooted the host.

Now, when trying to vmotion a guest to the patched how, we get the following warning from vmotion -

"Migration will cause the virtual machines configuration to be modified, to preserve the CPU feature requirements for it's guest OS"

This has never occured before on this host before upgrading it to U2 and appling the patch.

Performing vmotions to any other host in the cluster does nto produce this error. All hosts are identical hardware. This cluster did have DRS running on it for at least 2 moths before this issue. This host did have vmtioned guests on it before this issue.

Any help?

[Dollar]

"Migration will cause the virtual machines configuration to be modified, to preserve the CPU feature requirements for it's guest OS"

A "non-issue". This occurs (also) whenever upgrading versions..... at least it started occuring to me after the upgrade from 3.0.x to 3.5.... and will occur the first time a VM is VMotioned from a previous version host to a newer version host. I've seen it several hundred times. It will only occur on this first migration and will not occur subsequently, and has never caused me any grief, other than wondering what causes it.

[dougjef]

Overall I've had mixed experiences patching about 15 hosts. I've been using update manager. First I do a scan, then the remediation..It goes for about 10 minutes and then says VMware update manager had a failure. Generally a reboot of the host, re-scan, then re-remediate works. But I've only been successful patching two hosts without a reboot PRIOR to applying the patch.

[Kallex]

Hi!

Adding another success story of patching ESXi standalone:

1. Precautions: didn't turn the host time to anything, but did remove the time sync option on ALL the VMs. In case of patch failing, restarting the VMs would then be possible after host time change.

2. Downloaded the proper ESXi patch package

3. Downloaded the Remote Client for Windows and installed it (can be found here: )

4. Shut down all VMs, putting one in Suspend (test system, nothing important data within)

5. Putting host in maintenance mode

6. Tried out few referenced commands, ended up with the one

C:\tmp\setup>"\Program Files\VMware\VMware VI Remote CLI\bin\vihostupdate.pl" --server <my_server_ip> --username root -i -b ESXe350-200807812-O-BG.zip

7. Answered "yes" for reboot of host

8. Reconnected with VI Client after reboot, tried to re-execute the patch set (as I'm not familiar if it could have included other post-reboot patches), getting "Not applicable" for all the patches.

9. Exit maintenance mode, started VMs without any problems

10. Enjoyed the power of ESXi once again, starting ~10 VMs in parallel from 8 disk RAID10 SAS array with quite impressive startup times (no big penalty of huge parallel I/O burst)

Br,

Kalle

[RobertGreenlee]

On my hosts that have been upgraded to U2 and now this patch I'm geting a Configuration issue. HA agent on <host name> in cluster <clustername> in <datacentername> has an error. Not seeing any alarms through. Anybody have an idea what might be causing this.

Thanks

[Kallex]

I remember reading something about HA agent relating to host name cApItAlIzAtIoN differences between DNS and configuration causing issues with the U2.

I might recall wrong, but might be worth checking was it with HA and was it U2... definately there was some issue.

Oh and to be specific the issue was caused by the exact comparison failing for different casing. But you'll find the exact info on that in the specs once you find that exact issue.

Br,

Kalle

[Kallex]

Ok, found the issue myself as well... turned my memory wasn't that bad this time:

Br,

Kalle

[Dollar]

You'll need to get more specifics on the error by looking in the "Tasks and Events" tab. If the error is something to the related to the server name (or service console) not matching the IP Address in DNS (on any interface.. or something like that), even though they do, I have seen this as well (on two occasions)immediately following the intial reboot from an installation of U2. A subsequent reboot of the host resolved it.

[oturn]

Ok, I'm getting mixed messages here...

I see the crazy runarounds that folks are using to get this patch installed, but.....

Can we SCP and unzip the patch on our ESX hosts, then run esxupdate update -- WITHOUT the host entering maintenance mode, and WITHOUT affecting the running guests on the host being patched?

[RobertGreenlee]

I guess thats part of the problem.. I'm not getting any errors under Tasks and Events. I do not however have HA enabled at the moment. I'll turn it back on very soon afterI finish patching my last U2 host.

[RParker]

Looks Good! Nice Work VM Ware. It was rough 24 hours, but it appears everything is working well. I don't hold any grudges.. This was an excellent response.

Thanks!

[RobertGreenlee]

Well the HA error went away when I reenabled HA. I'll keep an eye on it. Beyond that I now have 3 of 5 ESX hosts on U2 with the patch. My boss wants me to wait until at least Friday before upgrading the remaining 2 hosts just to let this new patch bake a little bit.

Thanks

[vmproteau]

Update Manager question:

Is there a way to clear out patches and redownload. I still show instances of the the old 7/25 release patches in my baselines. I thought the next scheduled update would remove those but, they remain (see attached image)

[Nick_F]

Did the people that have updated via Update Manager just add the patch "Fix the time-bomb issues for U2" to a new baseline (on it's own) and remediate against that? Just wondering if I need to do anything else (only my second time using UM, the first time applied U2 and broke everything :smileysilly: ).

[RobertGreenlee]

I hate to go dlightly off topic with this next question but since it relates to Update 2 I'll go for it. We use HP BL 465c's and 685c's for our environment. I love the new hardware health monitoring as it will give us a way to send out alerts if we have hardware failures on the hosts. Unfortunately even through all of the components show up Normal the server itself is in Yellow state. I already have a case open on this but I'm curious if anybody else is seeing this.

[Troy_Clavell]

I have an 8 Node Cluster with 250 VM's, after the patch all powered on successfully and vmotion is now working again. I have set DRS to it's most aggressive state to test automation. So far so good