VMware Tools Bulk Upgrade (re-visited!)

[einstein-a-go-g]

I'm re-visiting this issue again, because I've never got it to function correctly.

Firstly, is there a need to maintain the correct/current version of VMware Tools in the Virtual Machines matching the Host build?

If there is I've noticed that the latest patches 20/02/2008 change the build number to VMware ESX Server 3.0.2 build-69376, this doesn't report correctly in VC 2.02 Build 62327.

and when I do the following:-This is not true, because the tools in the VM is Build 63195, and the latest tools is 69376! I assume this is due to the VC issue above!

Enter password for admin:

Connecting to VirtualCenter server on local port 902

Looking for VMs...

Found /DC/ToolsUpgrade/GuestVM21

/DC/ToolsUpgrade/GuestVM21: host is VMware ESX Server version 3.0.2

/DC/ToolsUpgrade/GuestVM21: VM is powered off, checking virtual hardware

/DC/ToolsUpgrade/GuestVM21: virtual hardware upgrade was not required

/DC/ToolsUpgrade/GuestVM21: tools are up-to-date. Skipping tools upgrade

and then:-

Enter password for admin:

Connecting to VirtualCenter server on local port 902

Looking for VMs...

Found /DC/ToolsUpgrade/EXDIAGS1

/DC/ToolsUpgrade/EXDIAGS1: host is VMware ESX Server version 3.0.2

/DC/ToolsUpgrade/EXDIAGS1: VM is powered off, checking virtual hardware

/DC/ToolsUpgrade/EXDIAGS1: virtual hardware upgrade was not required

/DC/ToolsUpgrade/EXDIAGS1: setting up tools upgrade...

/DC/ToolsUpgrade/EXDIAGS1: Failed to schedule tools upgrade. failed to fi

nd Windows system volume

I've tried many different VMs with different OSes! This looks like the same issue as before!!!!!

[stvkpln]

The version reporting problem is not, in fact, an issue with VC. It's an issue with the ESX host, and one I've brought up countless times in talking to VMware's development team. The reason the wrong version is reported to VC is because the version of the service VC is connecting to, hostd, has not had it's package updated with a particular package.. thus making the version you see when you execute 'vmware -v' at the command line different from the version being reported in VC. Want to confirm that, execute the following: 'rpm -qa |grep hostd', I'm fairly certain you'll see the version is the same as VC reports.

Now, to the question of the Tools update.. For the most part, there really shouldn't be a need to update within patched builds of the same release (i.e. within various releases of 3.0.1, etc). You should really be reading the release notes of all of the patches to determine their impact before being applied, and if there is a patch to the Tools package that may have impact on your VM's, you should take that under advisement and possibly upgrade if need be. A good rule of thumb is if VC is saying the Tools version is out of date, you may want to apply the latest and greatest just to be safe.

Generally, with Windows guests, when I've done the 'en masse' updates of Tools, it's worked on about 95% doing the non-interactive installation. Generally, it's going to reboot the VM, and it may lose network connectivity for a moment when the NIC driver is updated, so I don't recommend performing this during the day when the systems may be in use. Otherwise, you should be good to go.

[einstein-a-go-g]

# rpm -qa |grep hostd

VMware-hostd-esx-3.0.2-63195

correct!

But VC doesn't state Out of Date because it's knackered! But there is a new release of VMware Tools.

[dinny]

Yup,

It's still a "known" problem" with ESX 3.02 (and possibly 3.01)

VC does not report any of the tools as being out of date (since at least ver 43424) - similarly the first thing VMware's bulk tools installer does is check that the tools actually need upgrading (using the same (completely invalid) check).

So it does absolutely nothing.

I raised this with VMware support a couple of months ago asking for a workaround (no reply as yet....)

In the end I used psexex (from sysinternals) together with the vmware tools.msi and wrote my own script to update all my windows VMs

(There are a few old posts on vmtn about it)

Dinny

[einstein-a-go-g]

thanks, i'll dig through the posts and have a look for your scripts.

[dinny]

Hiya,

None of the posts were mine - but this was the command line I ended up using:

I forced a reboot - but you wouldn't have to I guess...

psexec -u domainname\account @comp.txt -d msiexec /qn /forcerestart /log c:\temp\vmtools63195.log /i "
server\c$\scripts\vmtools\VMware Tools.msi" REINSTALLMODE=vamus REINSTALL=ALL

Dinny

[einstein-a-go-g]

ah, yes, after searching through all your posts (you've been busy), my next posting, was going to be.....

thanks for posting again, I'll have a look a this.

[dinny · Accepted solution]

Pleasure

Please award points if it's useful

Ooh - I've just changed to a "knight" - how exciting

Dinny

[einstein-a-go-g]

points awarded!