savoy6
Contributor
Contributor

Patching Order is Critical?

Jump to solution

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

Did you power down the VMs before the storage?
0 Kudos
1 Solution

Accepted Solutions
acr
Champion
Champion

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

View solution in original post

0 Kudos
23 Replies
savoy6
Contributor
Contributor

older patch , not alder patch, as they may be poisonous:)

Did you power down the VMs before the storage?
0 Kudos
acr
Champion
Champion

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

0 Kudos
wobbly1
Expert
Expert

esxupdate -query to see what's installed Smiley Wink

you can use esxupdate -f I believe to force the installation of a patch out of sequence

0 Kudos
esiebert7625
Immortal
Immortal

fyi..here's a good patching document....

Patch Management for ESX Server 3 - http://www.vmware.com/pdf/esx3_esxupdate.pdf

0 Kudos
cheeko
Expert
Expert

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

0 Kudos
acr
Champion
Champion

using the -f option can be risky (its not best practise) as it omits the -querry therefore you can get dependancy issues..

0 Kudos
esiebert7625
Immortal
Immortal

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.

cheeko
Expert
Expert

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

0 Kudos
ANSA
Expert
Expert

OK guys... settle down Smiley Happy

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.

0 Kudos
esiebert7625
Immortal
Immortal

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.

0 Kudos
cheeko
Expert
Expert

So the fishes would be patches, right? Smiley Wink

Seriously: Let's hope that they improve the process soon.

Have a nice weekend!

0 Kudos
jrglines
Contributor
Contributor

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

0 Kudos
fdouma
Contributor
Contributor

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.

0 Kudos
fdouma
Contributor
Contributor
0 Kudos
oreeh
Immortal
Immortal

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

0 Kudos
ANSA
Expert
Expert

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

0 Kudos
fdouma
Contributor
Contributor

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.

0 Kudos
fdouma
Contributor
Contributor

Eeek

Should not have said "brute force install".

I never force, so I don't even want to say the word in this thread.

0 Kudos
skearney
Enthusiast
Enthusiast

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: Adding entry with key

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: Adding entry with key

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

0 Kudos