03.07.07
Time synchronization in a VMWare box running GNU/Linux
For a lot of the GCC and GNU Fortran development work that I’m doing, it’s much more convenient to work on a GNU/Linux box — the compilation process is set up in a way that is rather slow on Windows (even under Cygwin), and so testing changes is much quicker under Linux. On the other hand, my main computer runs Windows, and I don’t want to be running two computers all the time, much less be rebooting all the time. Thus, I’m running a GNU/Linux installation — Debian stable, to be precise — in a VMWare virtual machine. I can access the files on it via Samba and Windows file sharing almost as easily as files directly on my disk, and PuTTY is one of the nicest terminal windows I’ve used, and it generally is quite a nice way to do things.
One particularly nice feature is that, since all of the GNU/Linux stuff is operating in a single process on the Windows side, it’s easy to set the whole thing to a priority of BelowNormal, and thus even when I’ve got a compilation running and taking up as much CPU as it can hog, it doesn’t slow down anything else I’m doing at all. And it turns out that there’s enough slack in the system that this doesn’t give it any noticable lag in the terminals, even.
The one problem with that is that it completely confuses the software clock on the operating system in the virtual machine, though. When I’ve been using the CPU heavily on the Windows side of things, I’ve seen the GNU/Linux time lose 10 minutes out of 15! VMWare does a nice job of keeping the hardware clock up-to-date, but Debian is set up so that everything depends on the software clock, which only gets synchronized to the hardware clock on bootup. It’s not a critical problem, really, but it’s somewhat annoying to have to remember that a file date of three days ago (or whatever) means “a minute ago”.
The right solution to this is not ntpdate or some other NTP solution. The Windows clock is already synchronized over the network, and the VMWare virtual hardware clock is synchronized to that (I presume), and so there’s no need for adding extra traffic to the network. (Especially since it’s dialup, and disconnected from the internet and any NTP servers half the time.) Nor is the solution something like adjtimex, which tweaks the speed of the software clock; the time skew is a function of Windows-side computer load, and thus quite random, and a static speed tweak is not much of an improvement.
Instead, a better solution is hwclock --hctosys, which synchronizes the software clock to the hardware clock. Because the skew is quite large and needs correction quite often (and because cron is using the skewed software clock for timing, and thus loses time), I added the following to my root crontab:
* * * * * /sbin/hwclock --hctosys
So far, it seems to be working beautifully.
Nishant said,
August 1, 2008 at 2:55 am
Hey,
It doesn’t work if your clock is losing more than a minute in two minutes. Because the crontab fires by the system’s clock. So I saw the time update from 3:40 to 3:42 when the crontab fired.
hakre said,
October 5, 2009 at 2:28 am
I like the approach. Each time my windows host system is back from hybernation, the debian vmware boxes were out of sync with their software time.
I once used a timeserver / ntp to sync the clock again but after reading your post I much more like this version.
Brooks said,
October 7, 2009 at 12:37 pm
Nishant: Yes, that is a limitation of the idea; it doesn’t update more than every time the VM thinks is a minute. (Even if it updated every “real” minute, it would still be off by some seconds at the end of the minute, and this can confuse makefiles and such on shared filesystems.) For what I need, this limitation is more a matter of “isn’t as good as it could be” than “doesn’t work”, though.
hakre: Thanks for the comment; I’m glad to hear that it’s useful for you!