VMWare & the System Clock

The system clock behaves … strangely … under VMWare in a guest OS. It tends to run slow, and the amount by which it runs slow varies wildly from day to day. Without a fixed time synchronization source, guests will quickly fall out of synchronization and time-critical mechanisms such as Kerberos will break.

This happens because the guest OS assumes that there is a constant period of time between instructions – ie, it has all of the processor’s attention. The system clock is a high-precision clock maintained by this fact. When you put a guest OS into a virtual environment this goes out the window – the guest no longer has a consistent period of time between instructions, in general this time is longer than expected. Therefore means that individual ticks of the system clock take longer than the fixed (outside) time periods they should, and the system clock runs slow.

So, how do we stop this? Well, one solution is to use a guest-internal NTP client such as W32Time. This is a very bad idea. NTP clients adjust the system clock by slewing (speeding up or slowing down) the clock progressively so they can converge the system clock with NTP time. Since the system clock is running at an unpredictable rate, slewing the clock is a recipe for disaster – it causes the clock to swing to and fro and never stabilize. An unstable clock can cause very strange things to happen.

We could also just keep setting the time as we need to. This is also a very bad idea. Modern OSes rely on the continuity of time. If you just keep resetting the clock, the system ‘loses time’, and tasks that were supposed to run in the lost time just don’t happen.

The solution is to let VMWare Tools handle the problem, and check the box that lets it synchronize with the host. When you do this, VMWare Tools slews the clock appropriately so it doesn’t break anything, and your time converges as you’d expect. When you do this, you must turn off any other kind of time sync software such as W32Time, otherwise they will fight over the clock and much havoc will ensue.

There are certain times when you must run an NTP time server such as W32Time (such as on a domain controller). How you go about preventing W32Time and VMWare Tools fighting is an issue for another post.

NTP Time Synchronization in VI3

Time synchronization is of critical importance in a VMWare infrastructure. If it goes wrong, all hell breaks loose, especially in a Windows 200x environment using Kerberos.

Due to how system clocks work in VMWare, this means that you need to use VMWare Tools’ sync capability to keep your VMs right on time. This means that all your hosts need to be properly synchronized.

So, how do you do this? If you’re using any fancy deployment solution like Altiris, disable time synchronization in it. Why? Because if you don’t, you’ll forget six months down the track, virtualize your deployment solution, and then wonder why all your clocks go crazy.

Read this article and implement it. That’ll get your NTP daemon sorted out, but that’s not quite enough. You need to get your machine’s system clock and hardware clock in sync before NTP can slew the clock and keep it synchronized.

In order to do that, get into a console on your VI3 server, and do the following (I assume that firewall.contoso.com is one of your NTP sources, change to suit);

service ntpd stop
ntpdate firewall.contoso.com
hwclock –systohc
service ntpd start
watch “ntpq -p”

That will configure your system and hardware clocks to be close to the NTP source you named, and then start a watch process showing you the state of your NTP peers.

After a while, you should see an asterisk appear next to one of the peers (not LOCAL, that’s your host’s internal clock). When that happens, you’re all good.

Making a transform for any MSI installer

Many MSI installers will let you generate unattended installs, using command-line arguments, but they may not permit the use of a standard transforms (MST) file to make the unattended install. This is a major problem if you are attempting to deploy software via GPO, since you can’t specify a command line.

There’s a way around this, though. Go and get the Windows 2003 SP1 Platform SDK, and install ORCA from it. The SDK is a big download, but c’est la vie.

Once you’ve got ORCA up and running, make a copy of the MSI file you’re customizing (we’ll call them install.msi and install-cust.msi). Then open up install-cust.msi in ORCA. You will see a VAST number of tables. Don’t worry about them too much. Go find the Property table.

Editing the copied MSI

Now, when you use command-line arguments, what actually happens is the MSI inserts those into the Property table when it runs. So, let’s say you needed to add a TARGETDIR=c:\ argument into the Property table. Go look for the TARGETDIR property, and if you find it, edit it. Otherwise add it by right-clicking on the right-hand pane and clicking Add Row. Enter the values as appropriate. When you’re done, save and close ORCA.

Generating the transform MST

From a command prompt, get to a directory that has the two MSI’s in the same location. What we’ll run here is msitran.exe, a Microsoft tool that came with the SDK that generates an MST that’s the diff of two MSI’s.

Run the following command, and you’ll get a transform named install.mst;

“c:\program files\microsoft platform sdk\bin\msitran.exe” -g install.msi install-cust.msi install.mst

Voila! You now have an MST for your original MSI that incorporates the changes you wanted!

Manually running the MSI with the MST

In order to test deploy, you just run the following command. That runs the MSI, applies the MST you created, and does so in basic mode (which is what you’d typically use in an unattended install);

msiexec /i install.msi TRANSFORMS=install.mst

Assuming that works fine, go ahead and deploy via your method of choice.

First Post!


This blog is my first attempt at composing a blog and keeping it going. While most of the goings on here are IT-related, not everything will be.

Thanks for dropping by!