How to work around slow clock drift in a Xen domU

I have a Xen 3.2.1 server and the guests (domU’s), after a few months of uptime, are all behind about 45 seconds. Interestingly, the dom0’s clock is fine.

It seems that the hypervisor’s clock is what’s off as all the guests are off by the same amount. A reboot would likely fix it, but what fun is that?

There are a few ways to solve this. Most commonly, it’s recommended to tell each domU to manage its own clock. This necessitates the use of ntpd or the regular use of ntpdate in each domU though and seems like gross overkill for such a slow drift.

It is possible, however, to enable domU clock management briefly, reset the clock using ntpdate, and then return to Xen-based clock management.

To do just that, first move to domU clock management:

echo 1 > /proc/sys/xen/independent_wallclock

Then reset the time:

ntpdate -b pool.ntp.org

Lastly, return to Xen clock management:

echo 0 > /proc/sys/xen/independent_wallclock

This does have to be run on each domU. Perhaps there’s some way to actually reset the hypervisor’s time (which is where I suspect the problem lies—shutting the domU down and recreating it didn’t fix the time). If you know how to do so, leave a comment.

It would be pretty easy to add this to cron—even once per week would be enough in my case.