Every year I am confronted with another VMware guest time synchronization problem, it seems. I have become pretty good at debugging such problems :-)
You have 2 different unrelated problems. Either time goes too slow in a VM guest, which is fixable. Or time goes too fast in a VM guest, which is basicly impossible to fix by any time synchronization method.
For those impacted by this problem, it helped to remove and reinstall the VMware Infrastructure Client in my case.
I think I caused this problem because I first installed VI Client 2.5 before removing VI Client 2.0. It worked without a problem directly after the VI Client 2.5 installation, so I noticed only the next day that it suddenly stopped working with the error:
Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
For a customer we needed to know what the version of the ESX server is when provisioning a VMware guest. Since the VMwareTools package is significantly different for an ESX 2.5, ESX 3.0 or ESX 3.5 it was important that during the automated installation we selected the correct VMwareTools version.
When I have questions about VMware that go beyond my expertise I consult friend and VMware consultant Bert de Bruijn and also this time we looked at possible ways to find the information.
I just released a new Dstat. I finally spend some time doing the boring release-dance:
- Verifying all changes since 0.6.7
- Backporting changes to python 1.5 version
- Creating the release archive without all pending patches and experimental stuff
- Verifying ChangeLog and documentation
- Testing on all Red Hat and CentOS/RHEL versions
Have you ever been in this situation where the recommended solution is overly complex for a simple thing you want to do ?
Well, for a few months we have had issues with time synchronization on VMware guests. This is an old ESX 2.5 environment with fairly recent operating systems (RHEL4.6). The recommended way is to use clock=pit as a kernel boot parameter and to enable Host-Guest clock synchronization by either using vmware-toolbox (GUI!) or changing the .vmx files. In both cases a reboot is required for the time synchronization to kick in.
At a customer today I was confronted with a situation where VMware ESX processes had log-files open that were already deleted. This can happen when logrotate was incorrectly configured, or when operational staff removed big files to clean up diskspace quickly.
However when the file is still open, you can remove the file-entry (link) to the inode, but the diskspace will not become available until all kernel references to the inode are gone (and a process having the file open counts as a reference too).
Killing the VMware processes that had the file open was not an option since we just wanted to truncate the file without impacting the guests.