I've been out of touch with the ESX community for a while as I worked on a 6 month project, but I've freed up some time and can work on more fun stuff again ( yay ).
Anyway, I've written a script to take care of one of the more tedious parts of ESX v3, patching. I was inspired by this gentleman (http://virtrix.blogspot.com/2007/03/vmware-autopatching-your-esx-host.html), but his process didn't quite fit all my needs. I wanted something that would work via ftp, and all check the integrity of the patches before they were installed. The result is this:
If you like it, please drop me a line at firstname.lastname@example.org, if you don't like it email me and let me know \*why* you don't like it.
Great script, thanks dominic
Great script Dominic, many thanks. Patched 6 hosts, no problems.
Great script, thanks for taking the time to do it!
However, there is something definitely "erratic" about it for me. I am currently setting up 4 x brand new Dell 2950 (2 x quad-core 2.33 GHz) servers and each time I've run the script I've had a different result.
This leads me to believe that there must be a timing issue like other people have stated. I'm not a Linux guru, so I don't really know how to check it. I can tell you that even though the script goes right through, if I run it again there are ALWAYS patches that weren't put on the first time which it detects as not being installed. The patches that weren't installed are different each time. Sometimes it might only be 1, other times it might be 3 or 4. This is running the same script against the same FTP server with the same patchlist.txt.
I end up with errors because the patches have no longer been put on chronologically.
I used your same script to patch 6 machines at work the other day, and it worked perfectly on all of them. They are older machines though, so maybe the problem only happens on faster, newer machines?
Thanks again for a great resource!
Message was edited by:
Optic Nerve -
I've updated the script so that I think it should eliminate this behavior. Of course I can't be sure because I've never seen it myself. Would you be willing to test it out for me and let me know if you get better results?
So is everybody applying all the patches even the General ones?
@smsf - I did. Even if they had zero applicability to me, without a greater understanding of the dependencies involved, and the warnings about doing things in order that have been mentioned within this thread - I went ahead.
I could have probably should have done more due diligence with the versions of the RPM's contained within each of the Patch sets - but life (and time) is short
I was about to drop all the patches in the same directory (I have 1 for Critical and Security and one for General) and run the script but I was waiting to see if anybody is modifying the patch list in exclude the General patches that don't apply to them but yeah, many warnings about applying patches out of order so I am just going to go ahead and apply all patches.
Thanks Dominic for the script and thank all posters for the great info. you guys contributed.
Based on the feedback here I have modified the script to verify that the previous patch installs before proceeding with the next one. Optic Nerve did some testing and came back with positive results.
Thanks Optic Nerve!
I have also added support for local installs ( where patches already reside on the server ) and a --dry-run option so you can see which updates will be installed without actually installing any of them. You can find the script in the same place.... now updated to version 1.1
Just a follow-up to Dominic's last email. I tested the new version of the script on the same servers which I mentioned a few posts up. It worked perfectly on all four.
This was the first time all patches were successfully installed by Dominic's script on any of those servers, so I think the timing issue is fixed!
Sounds great! I have reinstalled another one of my ESXs and will try the new script in a few days (I have some other issues that need testing first on an unpatched system). I will get back with the results.
Thanks for the prompt fix for the issue!
I decided to go ahead and try it right away after all, since I have mirrored disks and can go back to the unpatched version for the testing (since this time I remembered to pull one of them out! )
Patching with the new version of the script went perfect. I didn't see any case where the verification actually saved me, but maybe just the verification process itself is enough to make it work, since it does take a second or so to perform. There were no errors in /var/log/vmware/esxupdate.log
After patching, running the script with the --dry-run option, it claims it would apply the ESX-6431040 patch. This is the same as on my first patched server, where everything went fine, and also the other re-installed one, where I installed the patches semi-manually. For some reason this patch seems special, in the sense that it does not get detected as already installed. I'm not sure wether it would be worth the trouble to try and make some special case handling for this patch - it seems esxupdate does nothing with it if trying to apply it again IIRC.
Anyway, great work! I change my recommendation to "go ahead and use, it's great"! Seriously though, the verification and eventual bailout on errors makes it feel safe for production use in my opinion.
Great Script Dominic!!!
Since with version 1.1 a local option is available, I misused it for installing from a san lun. The esxupdates are copied through fastscp or putty to the directory /vmfs/volumes/Template/esxupdates/ESX3.0.1 and are untared to the local directory /var/updates of a unpatched ESX.
The variables $Dir and $local I changed. The Variable $Dir is splitted
Thank you very much for creating this script.
This is the best support forum in the world!!
For those who can afford it for big ESX setups, have a look at
I just discovered Blue Lane, it's a patching system for ESX servers, I have not read about it at any great length because I have only one ESX box and I am still quite new to ESX.
http://weblog.infoworld.com/virtualization/archives/2007/03/blue_lane_provi.html, says it's $500/server, 45-day trial.
There is also a VMTN appliance at
Bluelane's VirtualShield is a product for patching the VMs, not the ESX servers themselves.
From what I understand, ESX patching will soon be incorporated into VC.
From what I understand, ESX patching will soon be
incorporated into VC.
That would be the ultimate goal. Hope its done soon.
By incorporated into the VC, do you mean the actual VC product or that this will be possible from the VC client??
Many SMBs who use ESX can't afford Std/Ent, the Starter version only provides the client.
Thank you, Tom
That's a good question and to be honest I'm not sure. I hope that this was taken into consideration.
Great Job Dominic, and Thank You! I will use your tool on our next ESX server rollout.
Thanks for this script; it's amazing useful.
I've created a small addition that uses your patchlist in order to download all of the relevent patches. Not sure if it's appropriate to integrate into your script, so I'll just paste it here.
\# Download all ESX 3.0.1 patches from VMWare website
\# based upon Dominic's list.
\# See http://vmprofessional.com/material/esx-autopatch.html
\# for details.
for i in `cut -d ',' -f2 patchlist.txt|grep -v '#'`
if \[ -f $i.tgz ]; then
echo "Skipping download for patch $i"
I seem to be having a slow Tuesday moment, but when I try to run ./esx-autopatch.pl --dry-run I get a "bad interpreter: no such file or directory" error. What am I doing wrong?