I installed all the patches I needed, then realized I needed another patch installed that i overlooked ESX-3199476. This will mean that it is installed out of order. What are the implications , if any? I understand the best practice is to install in order, but there may be changes in your environment that may at times cause you to go back and apply an alder patch.
Thanks,
miguel
Some Patches have dependancies but you would have known this had it been an issue during any of your installs.
You dont actually need to install all the Patches any way, you can be granular in your choice.
You should be good to simply install the missing Patch.
you can run esxupdate -q (i think its that one to query the Patches)
http://www.vmware.com/pdf/esx3_esxupdate.pdf
Message was edited by:
acr
older patch , not alder patch, as they may be poisonous:)
Some Patches have dependancies but you would have known this had it been an issue during any of your installs.
You dont actually need to install all the Patches any way, you can be granular in your choice.
You should be good to simply install the missing Patch.
you can run esxupdate -q (i think its that one to query the Patches)
http://www.vmware.com/pdf/esx3_esxupdate.pdf
Message was edited by:
acr
esxupdate -query to see what's installed
you can use esxupdate -f I believe to force the installation of a patch out of sequence
fyi..here's a good patching document....
Patch Management for ESX Server 3 - http://www.vmware.com/pdf/esx3_esxupdate.pdf
hey mr. siebert, do you really think that this is a good document?
I think it's quite vague - it doesn't mention anything about patch order at all, when I remember correctly ...
cheeko
using the -f option can be risky (its not best practise) as it omits the -querry therefore you can get dependancy issues..
Yes, it is a good general patching document for someone who wants to know more about patching. I didn't say it answered his question I just pointed him to a document that might help him understand more about patching. Hence the 'fyi" that prefized my post.
It's definitely ok to start with and see how esxupdate works.
My comment was more a critic on the overall patching experience within VI (which is definitely not enterprise ready IMHO), than an offense to your input.
As it's always good to RTFM, sometimes the manuals are not that great.
cheers,
cheeko
OK guys... settle down
On a more serious note, I think it's time that VMware jump in and offer an explaination. Savoy6 has a valid point. One might not need a General patch today, however, three months down the road situations change and the patch is required. It is true that it may be of no consequence, however the build number might not reflect the current ESX configuration and this could cause a 'tail-spin' should a service call be made.
No probem, I definitely agree that patching could be better in ESX. I like trying to educate people rather then just answer their questions.
You know the old adage...
You can give a man a fish and feed him for a day or teach him how to catch a fish and feed him for life.
So the fishes would be patches, right?
Seriously: Let's hope that they improve the process soon.
Have a nice weekend!
Great thread guys, thanks!
Ok, based on our experience, we can say YES, patching order is important. We went back and tried to apply a patch out of order and had to use the --force option. All worked out well in the end though but we applied all patches again in order with the --force option just to be on the safe side.
Regards,
JR
No, patch order is NOT important.
Don't force. People who do always have problems, then claim its a patch order issue. Force, under normal circumstances makes no sense - why do you ever want to go backwards?
I do it them in numerical order, always have.
Works every time.
See http://www.vmware.com/community/thread.jspa?messageID=617352��
Way too much FUD about this.
Frank D.
Corrected link:
http://www.vmware.com/community/thread.jspa?messageID=617352
definitely wrong, patch order is important
if you install all currently available patches in numerical order you get the result that is mentioned here http://www.vmware.com/community/thread.jspa?threadID=80531
or (if you are a lucky guy) some parts of your ESX host won't be up to date
Patching Order is not only Critical, it is also LOGICAL.
I quote from dominic7 response on this topic:
You will see that if you maintain your host on a regular basis then you wouldn't be able to install patches on a strictly numerical basis. Patch 2158032 that was released on 11/30/2006 is numerically greater than 1541239 which was released on 3/29/2007.[/i]
See this link for complete response
http://www.vmware.com/community/thread.jspa?messageID=617352
It is NOT critical, it is NOT logical, and it is NOT to worry about.
And dominic7 ain't god, either
Order doesn't matter.
Numerical works. And it works for all the right reasons.
See your /var/log/vmware/esxupdate.log, coupled with your CLI log as you patch.
One of the reasons you get the nastigram about using -force is due to the fact that some patches contain multiple RPM's. If you've installed an RPM by virtue of earlier patch, you get the nastigram, but the remaining rpm will be installed. (Caveat is that some have seen this not happen dependent on source of patches. I'm using a directory/NFS mountpoint to hold all patches). Also, you do, and SHOULD, get nastigrams about trying to install an rpm you already have, or already have at a later rev.
In this light, the "failure" is a GOOD one. You do NOT WANT TO INSTALL that rpm, since you already have it, or the rpm you already have is of later version.
Folks here seem to get all wrapped around the axle about seeing the message about the rev and needing the -force. It's NOT A PROBLEM. It's telling you the correct state of affairs.
Like I said, folks who automatically start forcing patches simply because of an error message get themselves into trouble.
I have happily, blindly, gone in numeric order since I installed 3.0.1, and I've had no problems whatsoever. All patches are applied, esxupdate query makes sense, VC looks right, everything works, always. For what it is worth, I've been a sys. admin. for 25 years, and patched more OS's than I care to think about. This isn't an issue of laziness, it's an issue of finding the absolutely most straight forward, repeatable, simplest method to maintain ESX. I have that with a numerical order, brute force install.
I just take the "error" as information, and it all makes complete sense.
Frank D.
Eeek
Should not have said "brute force install".
I never force, so I don't even want to say the word in this thread.
Well I'm not sure what to make of the difference between our experiences. Clearly, this log shows that I \_have_ to '--force' an update that contains a downgraded package. Not that I advocate doing that.
What the update provides.
\[root@xxxxxxxx ESX-1410076]# esxupdate -r file:/var/updates/ESX-1410076 -l info
Product : VMware ESX Server
Vendor : VMware, Inc. (support@vmware.com)
Release: : ESX-1410076
Release Date : Sun Nov 5 17:25:47 PST 2006
Summary : BSOD 0x109 during 64-bit Windows install
Description :
This update includes multiple fixes: a BSOD that sometimes happen during installation of a Windows 64-bit OS with Bug Check 0x109: CRITICAL_STRUCTURE_CORRUPTION; some situations where 64-bit VMs can panic with the message "unexpected panic:vmcore/vmm/bt/btassert.c:78"; a change for AMD Family 0Fh processors before Model F that some Read-Modify-Write instructions must be split into separate instructions to ensure ordering.
Upgrade paths : 3.0.1-32039
Repository URL: file:/var/updates/ESX-1410076
RPMs included :
VMware-esx-apps-3.0.1-34176
VMware-esx-backuptools-3.0.1-34176
VMware-esx-debug-tools-3.0.1-34176
VMware-esx-srvrmgmt-3.0.1-34176
VMware-esx-vmx-3.0.1-34176
VMware-hostd-esx-3.0.1-34176
What's installed:
\[root@xxxxxxxx ESX-1410076]# rpm -qa | egrep VMware-"esx-apps|esx-backup|esx-debug|esx-srvr|esx-vmx|hostd-esx"
VMware-esx-apps-3.0.1-32039
VMware-hostd-esx-3.0.1-32039
VMware-esx-vmx-3.0.1-42368
VMware-esx-srvrmgmt-3.0.1-32039
VMware-esx-backuptools-3.0.1-32039
Trying to apply update:
\[root@xxxxxxxx ESX-1410076]# esxupdate -n -v 10 -r file:/var/updates/ESX-1410076 update
DEBUG: Lock file /var/run/esxupdate.pid created with PID 2426
DEBUG: Options \{'url': 'file:/var/updates/ESX-1410076', 'verbosity': 10, 'noreboot': 1, 'enableRollback': 1} Command update
DEBUG: Entering \[ 17:40:39 04/10/07] \[ConfigState ]
INFO: Configuring...
DEBUG: Attempting to retrieve descriptor.xml from \[file:/var/updates/ESX-1410076/]
DEBUG: rpms created = 6 for tag='rpmlist'
DEBUG: Host version \[3.0.1] release \[32039]
DEBUG: LogCommand(grep vmware-vmx /proc/vmware/sched/cpu)
DEBUG: Configure yum.conf to use repositories
DEBUG: Saving descriptor to file /etc/vmware/patchdb/ESX-1410076.xml
DEBUG: Entering \[ 17:40:39 04/10/07] \[PrepState ]
INFO: Preparing to install VMware ESX Server ESX-1410076...
DEBUG: Prepare pending package list...
DEBUG: Matching package name 5 and NAVR 0
DEBUG: LogCommand(yum info)
DEBUG: updates = \['VMware-esx-apps.i386', 'VMware-esx-backuptools.i386', 'VMware-esx-debug-tools.i386', 'VMware-esx-srvrmgmt.i386', 'VMware-hostd-esx.i386']
DEBUG: newlist = \['VMware-esx-debug-tools.i386']
DEBUG: downlist = \['VMware-esx-vmx.i386']
DEBUG: upgrade pend : VMware-esx-apps.i386
DEBUG: upgrade pend : VMware-esx-backuptools.i386
DEBUG: install pend : VMware-esx-debug-tools.i386
DEBUG: upgrade pend : VMware-esx-srvrmgmt.i386
DEBUG: downgrade pend : VMware-esx-vmx.i386
DEBUG: upgrade pend : VMware-hostd-esx.i386
DEBUG: -- Total 6 pending 6 installed 0
DEBUG: Saving descriptor to file /etc/vmware/patchdb/ESX-1410076.xml
DEBUG: Entering \[ 17:40:39 04/10/07] \[PrepFailed ]
DEBUG: Install cleanup...
DEBUG: LogCommand(rm -f /etc/vmware/esx.conf.WRITELOCK)
DEBUG: LogCommand(rm -f /var/lib/rpm/__db*)
DEBUG: Lock file /var/run/esxupdate.pid deleted
DEBUG: Final state: PrepFailed
INFO: 1 packages need to be downgraded.
Please use the --force option and try again.
Error Code is returned by esxupdate... so any scripts could catch the error
\[root@xxxxxxxx ESX-1410076]# echo $?
2
Verify that nothing was updated
\[root@xxxxxxxx ESX-1410076]# rpm -qa | egrep VMware-"esx-apps|esx-backup|esx-debug|esx-srvr|esx-vmx|hostd-esx"
VMware-esx-apps-3.0.1-32039
VMware-hostd-esx-3.0.1-32039
VMware-esx-vmx-3.0.1-42368
VMware-esx-srvrmgmt-3.0.1-32039
VMware-esx-backuptools-3.0.1-32039