Hello,

I've been searching the web for about two days and have found sites that admit there are timing problems with KVM virtual machines but have not found a site that explains the problem in depth or how to correct it. Does anyone know of a good site that will explain the problems and how to correct them?

I'm running several VM Linux guests on a some Ubuntu hosts under KVM and all of them have severe clock issues. Within a week of setting the time and starting NTP they are all wrong by several hours, one was fast by nearly a day and a half. I've been a sys admin for nearly 20 years and have never seen such clock drift issues.

The physical hosts are all Dell 2850s and 2950s running Ubuntu with Kernel 2.6.28-18-server, that's Ubuntu 9 I believe (far more experience with RH than Ubuntu). The guest OS is RHEL 5.1. Running the command "cat /proc/cpuinfo |grep constant_tsc" does not produce output so I don't have a tsc on my CPUs. Since the guests are all RHEL 5.1 it is my understanding they don't use the para-virtualized clock either.

Any help will be greatly appreciated.

Although I don't know about KVM VMs, I do know that VirtualBox and
VMware VMs can have problems with time. It usually happens because
the system's timeclock assumes that the cpu runs consistently, but
in a VM (especially if the host uses frequency scaling) the cpu gets
varying numbers of cpu cycles per time unit. This is what causes
the drift.

A general suggestion is to not use time synchronization with the
host and then use ntp inside the guest.

You may want to search for suggestions for VMware time shift,
since I have seen a page that has different recommendations for
various versions of various distros.

1 members found this post helpful.

This seems to be the general consensus I've been finding on the web for various implementations of VMs. I read one post that suggested using NTP and disabling getting timing from the local clock. I've been trying the section on NTP recommendations and it seems to work.

http://kb.vmware.com/selfservice/mic...rnalId=1006427