As discussed at the 3/9 VMUG meeting, how to automate ESX patches using esxupdate and a patch repository FTP or WEB server. The following script example uses a WEB server.
Patches should be installed in order by month released (ie. First January, then February, March, etc.). For that reason, I prefer to group patches on the repository server by release date.
There should be no running VMs on the host prior to patching or patching may fail.
esxcfg-firewall -allowOutgoing
esxupdate --noreboot -r http:///esxupdate/03-29-07/ESX-9916286 update
esxcfg-firewall -blockOutgoing
Reboot after patching is complete
Also see the following URL for a specific issue to watch out for when using IIS as a repository server: http://www.vmware.com/community/message.jspa?messageID=595628#595628
Message was edited by:
jasonboche
I added the 3/29 patches to the script
Nice one, I found this today as well ![]()
http://virtrix.blogspot.com/2007/03/vmware-autopatching-your-esx-host.html
Kix!
Indeed a nice script, however, for security reasons, I disagree with this step:
On the HTTP Headers tab, MIME Types button: add .* and âapplication/octet-streamâ
See:
http://www.vmware.com/community/message.jspa?messageID=595706#595706
Good point, wild cards = scary.
Here is the script I had in my Power Point, it uses FTP insted of http, of course change the path to point at your ftp server.
esxcfg-firewall -allowOutgoing
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-1271657 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-1917602 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-2031037 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-2092658 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-3996003 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-5497987 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-6075798 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-2066306 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-6921838 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-8173580 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-9986131 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-1006511 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-1410076 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-2158032 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-3199476 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-5031800 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-5885387 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-6050503 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-6856573 update
esxupdate --noreboot --force -r ftp://192.168.16.200/vmware/updates/ESX-9865995 update
esxcfg-firewall -blockOutgoing
Message was edited by:
ctyke
A couple of questions:
1) where in the start up order to you put the script? s99xxxxx ?
2) do you gracefully shutdown the VMs first - just in case?
3) was there a particular reason that you used the FORCE option?
4) are you applying all of the patches just in case? many of them are to address very specific issues.
Thanks.
A couple of questions:
1) where in the start up order to you put the script?
s99xxxxx ?
The script is not run in any of the ESX startup scripts. The script is run on the Service Console after the server is booted up, through PuTTY would be best so you can copy/paste.
2) do you gracefully shutdown the VMs first - just in
case?
Absolutely. There must be no running VMs on the ESX server that you are patching.
3) was there a particular reason that you used the
FORCE option?
4) are you applying all of the patches just in case?
many of them are to address very specific issues.
I am but as some are hardware specific, it's not entirely necessary to install all of them.
Thanks again Chris for your presentation on 3/9. It was excellent! Don't forget to sign up for the VMware Core Customer Program so you can have points added to your account for your VMUG presentation. If you are unsure of how to get started in the VMware Core Customer Program, contact me via Email and I can help you out.
Jas
We used the force option because some of the patches didn't take. We found this option recommended in some of the forums.
I will have to investigate that. -force sounds like a good thing because I'm not interested in failing patches.
On the flip side of the coin, inquiring minds want to know why the patches would fail w/o the -force option, but they install successfully with the -force option? Perhaps the ESX host does not meet one or more of the patching requirements at the time of patching?
Examples off the top of my head:
1. There are running VMs on the host?
2. Host is not in maintenance mode?
3. Patches are installed out of order, thus older versions of patches are being installed over the top of superceding patches?
4. Improper version of ESX for the patches that are being installed (ie. installing 3.0.0 patches on a 3.0.1 host)
5. ?
One thing you want to make sure is to keep the patch order in line with their release dates: especially when patch filenames are not sequential and when you use Re: esxupdate patch scriptforce[/b] option. If you don't consider this, then you will end up overwriting newer rpm with older version.
ESX-3199476.tgz (New) and ESX-6075798.tgz (old) is a good example. They both have updated VMware tools ISO files and if you just go with file name and force option while applying all patches at once, you will overwrite newer tools with older version. Without force option esxupdate will not downgrade a patch.
That is why in my web repository for patches, I'm choosing to make sub directories which the names are based on the release date as per VMware's download website.
Then by looking at the patch script, I can tell what order they are being installed in respective to what date they were released. ie. November, December, January, March, etc.
As far as what order I'm installing inside of one month, I'm just going in order of the patch number ASCENDING order, assuming it doesn't matter anyway, ie. no patch in March would supercede another March patch!
Sounds right.
My point was just to say use -force with caution.
I would not force a patch as a default action.
Like you said, I would want to know if a patch install failed and determine why instead of just forcing blindly.
Jason,
I have a very nu-bee question to this ftp depot patching procedure. Does the "ESX-#######" refer to the folder created after tar'ing the .tgz file and the esxupdate knows that it needs to go in there to find the update?
esxupdate --noreboot -r http:///esxupdate/11-30-06/[b]ESX-1006511[/b] update
/esxupdate/11-30-06/ ESX-1006511
In the above example, if the ESX-1006511.tgz file was put in the esxupdate/11-30-06 directory and untared it would have created the directory ESX-1006511 under it with the rpm(s) in it.
Else the file could have been untared elsewhere and the files could have been copied to the esxupdate/11-30-06/ ESX-1006511 directory.