Well bugger. I was just finishing the patching of our last server.....
Thanks Brian.
Unfortunately that is not the present VMware admins have been hoping for. A overhaul of the whole ESX patching process would have been a much nicer present.
I still hope the next VC update brings some sort of patch management for ESX...
lol, the patch list is already updated but no files
ESX-4825991 Patch | 05/15/07 | Critical Patch
ESX-5095559 Patch | 05/15/07 | Security Patch
ESX-5140477 Patch | 05/15/07 | Security Patch
ESX-6657345 Patch | 05/15/07 | General Patch
ESX-6704314 Patch | 05/15/07 | Security Patch
ESX-7281356 Patch | 05/15/07 | General Patch
ESX-7302867 Patch | 05/15/07 | Critical Patch
ESX-7408807 Patch | 05/15/07 | General Patch
ESX-7557441 Patch | 05/15/07 | General Patch
The files are there, the documentation links just don't work yet.
try http://download3.vmware.com/software/vi/ESX-7557441.tgz for example and change the patch number.
I would recommend that it is about time for a 3.0.2 in order to simplify things a little, but honestly that would be much worse. When we get to that point, all my VMWare Tools will be out of date which means I have to reboot every VM in my environment in order to get to the latest rev. You think keeping up with these little patches is the problem - it's nothing compared with when a new minor rev comes out. Those are the ones that are a pain. I say keep the little patches coming as long as possible (or until they improve on the upgrade for minor revs).
Does anyone else just let the VMWare Tools version fall behind the ESX version it is installed on? I'm not saying run 2.5 Tools on a VM running on a ESX3 host, but what about upgrading to a future 3.0.2 release, but keeping the Tools version at 3.0.1? I do it more than I'd like to admit and haven't had issues that I'm aware of - anyone else?
Lastly, the risks of upgrading to the latest Tools is not negilible. Anyone else gotten the BSOD on a VM after upgrading the VMWare Tools? I won't hardly do it anymore without an uninstall/reinstall or without making a snapshot first - either way is incredibly time consuming, which is why I opt to not do it often times.
The patch process is a pain, I usually don't even apply them unless they are critical and apply to my situation. I think i've only applied one or two patches since 3.0.1. It is about time for a new minor release, or major release for that (3.1?)
My point, though, is that as painful as patching is, upgrading to even minor revs is an even bigger pain. To do that correctly every VM has to be rebooted (their Tools have to be upgraded). To add to that pain: if you've upgraded enough Tools releases, you've eventually ran into a VM that blue screened after the reboot. It's rare, but if you do it enough you'll eventually come across it - it's not as likely when merely upgrading a minor rev, but there is a risk involved - one with a small likelihood but a large impact. Upgrading is a much bigger pain than patch installations since some of the patches don't even require the ESX server to be rebooted.
I would much rather continue hand-picking the patches I require as long as possible as opposed to upgrading to a new rev. It's the lesser of 2 evils.
A overhaul of the whole ESX
patching process would have been a much nicer
present.
Amen!
/k
From another post
"VMware ESX Server 3.0.1 build-44686
oldTools: 41412
newTools: 43424
So it looks like all VMs will need new tools installed.
"
So you have to upgrade the tools anyway for the minor patches.
Yes, but VC doesn't tell that they are out-of-date....
Where can I find the tools version on a server?
Vmware Tools (on a VM)
o Right-click on icon inside VM
o Click on About tab ie. build-32039 this should match your ESX server version
Vmware Tools (on a ESX Server)
o Login to service console
o Type rpm qa | grep VMware-esx-tools ie. VMware-esx-tools-3.0.1-32039
I feel like I'm running all my VM's on a Windows host since I am patching almost as much....
As you seem to have updated a server can you confirm that the version shown via the service console 44686 is also the same from within the VI client?
I've got a clean test box which I applied all 34 patches to in 1 hit and I see 44686 from the service console but 42829 from VI client.
I thought we'd sorted this bug out last time round.
Ah no no, it is easier to patch on windows, it almost goes automatically.... (and no i am not a windows fan)
I concur with the earlier made statement that patching on ESX is a pain right now, time to automate it and as for the patches?
As long as they are not in the official download links, i refuse to touch them.
--
Wil
Well they can be automatic, but in the enterprise thats never the case and since i have to reboot every damn VM anyhow I might has well be shutting down VM's and patching a Windows host.
Obviously not the same due to vmotion,etc but still too many patches for my liking.
It not the frequency that's painful - it's the difficulty when the Tools get out-of-date and need upgrading that makes it painful.
I don't mind the frequency. Those who administer enterprise-class applications from Oracle, Apple, PeopleSoft, SAP, or anywhere else are used to having patches and hotfixes dribble out every month or so. It's just part of having a large, complex system. We blame Microsoft because the masses out there interact with Microsoft's patch mgmt solution whereas they aren't aware of the other companies that do the exact same thing. Perhaps as the iTunes/QuickTime/Acrobat/Java/RealPlayer apps continue displaying pop-ups every month touting the new release they are ready to install for you this blame being put on Microsoft alone will start to subside.
Well they can be automatic, but in the enterprise
thats never the case and since i have to reboot every
damn VM anyhow I might has well be shutting down VM's
and patching a Windows host.
Guess i should have defined "automatic" as in that i don't want to have to:
\- check the patches list daily
\- download them manually
\- md5sum them to make sure they are ok
\- then apply the ones i need/want at a time which is convenient for the server
I know we can get some scripts to automate them or write those myself, but that also means that if there's problems, i'm up the creek. There's already enough work on my plate, so would prefer the more automatic approach as in windows.
Heck i would love to see something like apt-get, maybe even yum... or would even settle for a cvsup type of approach. Although the latter one requires us to get all the sources which is a no-no for vmware.
Obviously not the same due to vmotion,etc but still
too many patches for my liking.
I really don't mind having more patches as in the 2.5 days, but i dislike the way we have to apply them. Especially since it is YUM underneath it all, so it could have been so MUCH easier to apply if they would have copied it properly from red hat/fedora.