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.
Superflit's steps worked well for our ESXi farm. The rest of the ESX 3.5U2 servers were updated successfully with Update Manager. Fortunately we had a server free of VMs so it could be put into maintenance mode without powering off any VMs.
Not sure if this has been experienced yet or not as I haven't read thru all the posts on the subject. Our dev infrastructure is as follows: 54 hosts, 300+ VM's, ESX 3.5U2, VC 2.5U1, all local host storage...no shared storage thus no vmotion, HA or anything else. Update Manager worked like a charm. Updated all hosts tonight. One interesting observation is the fact that updated hosts that were NOT rebooted and have NO VM's on them seem to be running at about 60% avg CPU load. Updated hosts that were NOT rebooted WITH VM's on them seem to be ok, but the host still running "hot". Updated hosts with or without VM's on them that DID get a reboot are fine. Don't know if this is because VC is running U1 and ESX running U2, and the perf charts getting flawed, or whether this is a problem with not rebooting the hosts. As soon as I reboot a updated host with no VM's (previously running at 60% CPU) it flattens out and runs fine, typically at about 2-3%. Thought the guru's at VMware might want to test this out. Object "0" on the CPU perf chart is at near 100% until I reboot. I assume this is the Service Console? We run 800Mb RAM on the SC. If you don't max the RAM on the SC, cold migration is painfully slow. Can't wait for shared storage (coming soon!)
PS. Suggestion for the next release... provide a way to kick off automatic startup of VM's from the Service Console as provisioned in the VM Startup/Shutdown config.
Is anyone else having difficulty installing the patch via the esxupdate method? I keep getting an error saying 'Descriptor release (ESX350-200806812-BG) doesnt match directory name' when installing it on our ESX 3.5 server. I've tried downloading the patch twice but still the same error. We've only just installed ESX and I setup the patch depot on a server that is running Apache 2.2.
The website exists and works so not sure what is wrong.
Patching via gui (remediate option) went fine for two hosts. On one host however, which was not running update2, the remediation failed with a "general error" and disconnected from VI. After a reboot it shows that U2 failed to apply, but the patch to fix U2 did apply---- shurely shome misstake here. Must we apply all patches except the U2 fix and then apply the U2 fix?
Just wondering: Did anybody manage to add a VMware Server to the VC after the patch?
We have several ESX server and some lonely and old VMware Servers.
I get "A general system error occurred: internal error" when i try to add a VMware Server.
I'm trying via esxupdate and was getting the same result:
I was typing the following :
esxupdate -d /var/www/html/esx35/ESX350-200806812-BG/ scan and getting this error.
I then typed "esxupdate -d /var/www/html/esx35/ESX350-200806812-BG scan" without the slash and worked.
Only one problen i am experiencing. whe I do a -- test update I get:
INFO: No -b specified, selecting all bundles in depot.
ERROR: Integrity Error!
Why the imtegrity error?
we had one host which did not have update 2 and that successfully applied the fix and cheerfully ignored update2!. On the U2 hosts though we just remediated against the standard baseline and it all went ok.
I'm a little (just a little) disappointed in VMware's tech support on this. We have Platinum Support, and I requested an email as soon as the express update was available (it was supposed to be posted Tuesday night) I never got any notification, when I got into work on Wednesday morning, I saw the update was available. I know they must have been flooded with requests, and I was able to get the update myself.
That being said, I had no problems downloading the update, and I was able to apply the update to my servers with minimal downtime. Our Tier 1 & 2 hosts are lightly loaded and I was able to find a host that had a clustered VM and a VM that was not yet in production, so I started my patching by updating that server. I was then able to VMotion VMs to that host to patch others, I got Tier's 1 & 2 updated during normal business hours with no users impacted.
Tiers 3 & 4 were a little different. That cluster is more heavily utilized and there is less headroom. I had to wait until after normal business hours to start the patching, I took all test/dev VMs down (leaving more headroom) and in all only had to take two production systems down for a total of about 15 minutes.
All-in-all, I'd say the process went very well. I was hoping that there wouldn't be a requirement to shutdown VMs to apply the patch, but even so, having two VMs down for 15 minutes to update 14 hosts with almost 100 VMs is not too bad.
I had to put it on the local machine, cd to the repo directory, and do
straight "esxupdate update" in order to get it to work. It doesn't seem
to like having the directory/location specified on the command line.
I manually performed the update on the hosts:
1. Shut down or vmotion all VM's off host. Unfortunately our primary DC was on the first host I patched, so I had to just shut it down, no problems doing that because we have a backup DC.
2. Using WinSCP, I put all of the files for the update in my /var/updates directory.
3. Put host in maintenance mode as esxupdate would NOT function without being in maintenance mode(usually normal but I recall seeing some people say they did NOT have to do that)
4. Esxupdate -n update
5. service mgmt-vmware restart
6. Brought host out of maintenance mode>
7. Dealt with the fact my hosts never reconnect to the virtual center server automatically by doing a manual disconnect and reconnect of host.
8. Powered VM's back on, worked like a champ.
Not too shabby!!
2 of my 5 servers are still running update 1. the other 3 were patched yesterday with the hotfix. I'm planning on bringing the U1 using Update Manager tomorrow so now that they released the new version of U2 I told Update Manager to download it. It did do that but it also duplicated the original 16 patches and the old U2 version. I've attached pictures so you can see. The first U1.jpg pic is from a U1 host that needed U2 and some other non-critical patches. The U2.jpg pic is from a U2 host that was patched yesterday. It already has the original version off all these patches but after telling it to Scan for Updates it was to reinstall all of these.
I know I can pick and choose the correct updates but I'm looking for a way to cleanup these duplicates.
Same issue as RobertGreenlee here - anything with the express patch shows u2 and the other re-released packages as non compliant.
We need a KB from VMware here to close the loop on all of this!
I'm applying them to one of my u2 hosts that doesn't matter just to see what happens...
As I watch the progress I'm noticing VMware tools is the new build version as well, my guess is we might see the u2 original tools installs marked as 'out of date' in VIC after these are applied...
Ugh, perhaps there is plenty more cleanup to do yet....