What do you mean by the automatic approach? Do you leave all your windows servers/desktops on automatic updates without evaluating every patch in a test environment and then deploying them to groups?
I am managing 30 clients and the largest client has close to 500 desktops now and 60 servers including solaris/Oracle.
Every patch for every application/vendor goes through testing and change management with signoff before being deployed.
ESX goes through the same thing, but now I have to work out the ESX patching with my Microsoft patching to make sure a Patch doesn't get installed and then the Tools updated without a reboot in between to ensure I don't bluescreen anything (a remove of software and a patch at the same time can cause this - I've had to fix servers because of this)
The ESX script I am using from the forums helps alot with the automation of the esx patching, but the tools install afterwards is a bit of a pita...
What do you use to sync up the VM tools installs inside the VM's to the updated ESX build? I've been using Dominic's patch script but havnt found anything good to handle the tools upgrade.
I've seen posts saying that vmwaretools-upgrade should work but I cant get it to work properly.
For now its been run the install manually and then reboot...
I haven't tried any scripts for that, mainly because I never actually thought about that...
Would make sense to do that though wouldn't it...
What do you mean by the automatic approach? Do you
leave all your windows servers/desktops on automatic
updates without evaluating every patch in a test
environment and then deploying them to groups?
\[wil] LOL, no i test them too.
I am managing 30 clients and the largest client has
close to 500 desktops now and 60 servers including
solaris/Oracle.
\[wil] Congrats, i'm not a "real" admin as in my main work is software development, but i do have clients in all continents. But i do administrate a small army of servers/desktops for several clients including windows, linux, *BSD and Solaris.
Every patch for every application/vendor goes through
testing and change management with signoff before
being deployed.
ESX goes through the same thing, but now I have to
work out the ESX patching with my Microsoft patching
to make sure a Patch doesn't get installed and then
the Tools updated without a reboot in between to
ensure I don't bluescreen anything (a remove of
software and a patch at the same time can cause this
- I've had to fix servers because of this)
\[wil] That's what i try as well, but i can't help it if i miss a sync here or there causing an extra reboot (too bad). The real issue is if you end up in B/P SOD land.
Especially if it is a remote physical machine (esx or not)
The ESX script I am using from the forums helps alot
with the automation of the esx patching, but the
tools install afterwards is a bit of a pita...
\[wil] There you go... you are using an unsupported solution that - if you're outta luck- might even take your entire ESX server out of support. Even the scripts can make mistakes, actually i would say it is much more likely that the scripts goes hayward as the patches themselves.
We should need no scripts from external sources for managing a simple task as this.
If you have SMS or something like that you can send it out as a package
I am not actually using an unsupported script. All the script does is do exactly what I'd type at the command line.
Install X patch no reboot
Install Y patch no reboot
Nothing spectacular about it or really tough either and vmware fully supports typing the same command at the console and doesn't care if you script it.
Its not like I am manually extracting the patch and then copying the files to where they are supposed to go and registering them,etc.
I know, i was just trying to make a point. The reason you know the script is safe to use is because you understand the script by reading it (there you go, you're a programmer too)
But not every script is without mistakes and not all mistakes are obvious.
Now what i would like to see from vmware is something along like this:
\[root@ESX1 ~]# yum update
Setting up Update Process
Setting up repositories
core 100% |=========================| 1.1 kB 00:00
updates 100% |=========================| 1.2 kB 00:00
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 549 kB 00:00
updates : ################################################## 1676/1676
primary.xml.gz 100% |=========================| 1.8 MB 00:02
extras : ################################################## 5802/5802
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package fuse.x86_64 0:2.6.5-1.fc6 set to be updated
---> Downloading header for openldap to pack into transaction set.
openldap-2.3.30-2.fc6.x86 100% |=========================| 32 kB 00:00
... snipped.....
---> Package gsm-devel.x86_64 0:1.0.12-3.fc6 set to be updated
--> Running transaction check
Dependencies Resolved
=============================================================================
Package Arch Version Repository Size
=============================================================================
Updating:
firefox x86_64 1.5.0.10-6.fc6 updates 17 M
fltk x86_64 1.1.8-0.3.r5750.fc6 extras 424 k
foomatic x86_64 3.0.2-39.5.fc6 updates 15 M
fuse x86_64 2.6.5-1.fc6 extras 78 k
fuse-libs x86_64 2.6.5-1.fc6 extras 56 k
.....snipped....
Transaction Summary
=============================================================================
Install 0 Package(s)
Update 17 Package(s)
Remove 0 Package(s)
Total download size: 65 M
Is this ok \[y/N]: y
Downloading Packages:
(1/17): fuse-2.6.5-1.fc6. 100% |=========================| 78 kB 00:00
...snipped...
(17/17): gsm-devel-1.0.12 100% |=========================| 12 kB 00:00
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Updating : openldap ####################### \[ 1/34]
....snipped....
Cleanup : gsm-devel ####################### \[34/34]
Updated: foomatic.x86_64 0:3.0.2-39.5.fc6 fuse.x86_64 0:2.6.5-1.fc6 ..snipped...ypbind.x86_64 3:1.19-7.fc6
Complete!
You see, 2 words and Yes or NO
That's all you need to do for keeping the host up to date if it was "automatic"
Message was edited by:
wil, removed some more non info so our messages aren't as wide.
Did VMware pull the patches? I do not see them listed anymore
yip, refreshing the page makes them disappear. I suppose they are just fixing the download links, but who knows?
Maybe the patches are no good and they need to go back to the drawing board. That's why they probably pulled them off the website.
Michael
You just had to bring up sms didn't you???
Not respectfully,
For the love of everything big and small, Please VMWare make 3.0.2 or please send some engineers to patch my 16 ESX hosts and 300vm's
And I know i don't even have close to the biggest farm...
The latest I've heard on 3.02 is June 20th now.. Then again depending if QA finds more issues.
Where did you hear that from? They're usually pretty tight-lipped about any kind of release dates.
Even if you did here that, I assume you just broke your NDA
Dave
Only 16 hosts and 300 VM's. Lucky you.
As far as the SMS commentary. Sure am glad we have it here.
About upgrading the tools. What's the documented/best practice logic. This is really the first conversation I've read where it's assumed everyone is doing it after host patches. We're probably running tools from the original build on quite a few guests. I've never had a problem that I am aware of.
That said, I don't mind getting the SMS group to push the upgrade out to an OU. Beyond the reboot it's painless and should work like a charm. I'll be engaging that group to create a package and push it out to a test group first thing in the morning. I am just curious as to what is the primary benefit Pretty much all windows VM's syncing with DC's. Again, never had a problem with that though I have read recommendations to use VMTools and a host sync instead of using windows time. Which is fine, I have all my hosts syncing to an a ntp pool.
Veterans? Why should I upgrade tools on 400+ VM's? What's it buying me? No sarcasm there. I am genuinely interested in the reply.
Do a search someone has posted how he did a silient SMS push of the tools
I have let VMWare Tools get out of date as well and haven't seen issues either. The only concern I have is that VirtualCenter will tell you to upgrade the Tools if it's out-of-date. Like you and I have experienced though, it's not necessary that we've been able to tell. If it's good then I'd like more explanation than "just do it" but if it's not needed then I don't want VirtualCenter to tell me it is.
By the way, I just noticed that one (I think only one) of the patches mentions that it is necessary to upgrade the Tools. The patch specifically addresses an issue with the Tools, so that makes good sense. So can we take that to mean that the other patches don't need the Tools upgraded (even if VirtualCenter reports otherwise)?
By the way, I just upgraded Tools this week on a VM and the upgrade caused the VM to be unbootable (BSOD on all startup modes). Luckily it was a VM I was migrating from 2.5 to 3 so I had kept a backup of the 2.5 VMDK files. I tried the exact same sequence but instead fully uninstalled the 2.5 tools and reinstalled the 3.01 tools fresh and this worked fine. I migrated this VM exactly like the 30 other VMs I've migrated so far with no issues - until this time.
I've also heard that installing Windows updates and upgrading the Tools all without a reboot inbetween can cause the BSOD on startup also. Rest assured there is some risk in installing the Tools. I also ran into issue with Windows where occasionally the VM would think it got a totally new NIC therefore the static IP settings were gone and I had to go reset them before the VM would communicate on the network. If you script it for that many VMs, I'd recommend putting some sort of Snapshotting into the scripting process (for instance: take a snapshot, do the upgrade, once the server is up and responding on the network for a 5 minute period then delete the snapshot).
One thing I've gotten into the habit of is when I'm rebooting a VM for maintenance/upgrades/etc, I'll go ahead and upgrade to the latest Tools (unless, of course, it's Windows Updates I'm installing). That seems to keep most VMs up to snuff.
For those using esx-autopatch.pl script to update their ESX, here is the new patchlist.txt:
\# ESX v3.0.1 Patch List with MD5SUMS
\# Updated 5/16/2007
\# Updated lists available at:
\# http://vmprofessional.com/index.php?content=resources
001,ESX-2158032,c688275383addb789af1885ef4632b5f
002,ESX-1410076,7208b58046546b11593a38e5ce9f23b8
003,ESX-1006511,efa86b4e30e7700e186c8040fde93381
004,ESX-9986131,239375e107fd4c7af57663f023863fcb
005,ESX-8173580,1a4f3e57d1b950dec8401074aaa92490
006,ESX-6921838,49ae671c886a00dd68ceb4b9e3d9e5ee
007,ESX-2066306,2b8a9a6d9beb82476e1a7e8eafbb18d7
008,ESX-6075798,c6df2ed7bc6e918ea8a77a220d543948
009,ESX-5497987,a72de3579bf0a466ef4f14f3b454b60e
010,ESX-3996003,58e9581f338c9fb783e72028a6f15ba4
011,ESX-2092658,8196dd7c0d39fe7bf8147ec198083bbe
012,ESX-2031037,2df5b252b82f5a33be64513fad8daef7
013,ESX-1917602,23d76165dc8032ef18f368d983628169
014,ESX-1271657,3fc76e076d6334b71d4158c123eab4af
015,ESX-9865995,9223fe857d94a3bc4098a8c93b753be2
016,ESX-6856573,16bb030929bb005fe26c09f637cb9cd8
017,ESX-6050503,d1cb2751abb1acb9951c368fd4cccaa0
018,ESX-5885387,423e29b266f0d3181f2211dc6679b63e
019,ESX-5031800,c266474de27c569631b93bf566ad74f2
020,ESX-3199476,a12c77bd49c65f7a333dd8e70a6ec729
021,ESX-9916286,7b98cfe1b2e0613c368d4080dcacccb8
022,ESX-6431040,ef6bc745b3d556e0736fd39b8ddc8087
023,ESX-2559638,9ee9d9769dfe2668aa6a4be2df284ea6
024,ESX-2257739,e49ae9be1c51fef5db641e0654a43117
025,ESX-1541239,e8e83b996daedd967ed033f1c1292a3d
026,ESX-7557441,2a9b7ea008d51a9ac746b3c32ea36ccf
027,ESX-7408807,6afceb8ed6cd6118eb6593c7ef98b721
028,ESX-7302867,a3449ef90ed8f146596c9dac27f88d41
029,ESX-7281356,6cf69200201c6c29b1aeade4e0de4140
030,ESX-6704314,2470567517a64726b1c5929c59ed6134
031,ESX-6657345,4004da51cb28a128ec88dd8f90c23494
032,ESX-5140477,05db3ff9c3c51375a480da3f74a517e8
033,ESX-5095559,bcded4127598c22d47f06ab03366d2f8
034,ESX-4825991,083290f1b0753a70cff81553e7cfd069
Why should I upgrade tools on 400+ VM's?
What's it buying me? No sarcasm there. I am
genuinely interested in the reply.
With the tools out of sync i've seen the VMs being less responsive as usual, then there's the "eating memory" issue which if i am reading this[/url] correctly is solved now.
That alone is enough reason to upgrade, but with that many VMs you surely don't want to do this by hand.