The system time appears to drift on VMWare ESX Server 3. This problem can be replicated by booting the livecd and running ping. Real virtual machines show the same issue. I have tested both 2006.1 and 2007.0, and both exhibit the same issue. The system time appears to remain accurate throughout. VMWare Tools doesn't seem to make a difference. You can demonstrate the problem by printing out a high resolution timer to a file and looking for any decrease in time as the file progresses. A simple ping will also show the issue. Other distributions do not exhibit this issue. I have tried both Redhat and Ubuntu. The problem is also not evident on the x86 architecture, only x86-64. I have tried several kernel revisions as well, and the problem persists. PING server (ip) 56(84) bytes of data. 64 bytes from server (ip): icmp_seq=1 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=2 ttl=64 time=5.18 ms Warning: time of day goes back (-4685us), taking countermeasures. Warning: time of day goes back (-4685us), taking countermeasures. 64 bytes from server (ip): icmp_seq=3 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=4 ttl=64 time=1.26 ms 64 bytes from server (ip): icmp_seq=5 ttl=64 time=0.409 ms 64 bytes from server (ip): icmp_seq=6 ttl=64 time=0.313 ms Warning: time of day goes back (-614us), taking countermeasures. 64 bytes from server (ip): icmp_seq=7 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=8 ttl=64 time=4.00 ms 64 bytes from server (ip): icmp_seq=9 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=10 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=11 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=12 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=13 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=14 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=15 ttl=64 time=3.88 ms Warning: time of day goes back (-3212us), taking countermeasures. 64 bytes from server (ip): icmp_seq=16 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=17 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=18 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=19 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=20 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=21 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=22 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=23 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=24 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=25 ttl=64 time=3.43 ms Warning: time of day goes back (-2683us), taking countermeasures. 64 bytes from server (ip): icmp_seq=26 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=27 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=28 ttl=64 time=0.000 ms 64 bytes from server (ip): icmp_seq=29 ttl=64 time=0.000 ms --- server ping statistics --- 29 packets transmitted, 29 received, 0% packet loss, time 28009ms rtt min/avg/max/mdev = 0.000/0.637/5.189/1.437 ms
This is not a Gentoo problem. It is a known ESX issue (I have it here on all 800 virtual servers we are using with VMWare ESX 2.5.x and with 3.x. In RHAS 4u2 and in various Windows editions). You can read more on that issue at the knowledge base of VMWare. Quick fix/workaround: You need to install the latest VMWare tools and then enable on the VM to use ESX as the source for the time sync (in Virtual Center select the VM and then edit the properties and then go to tab Options and then select Advanced and then press button Configuration Parameters ... and then add/change tools.syncTime to TRUE). This will solve your problem.
As said above, this needs to be fixed by vmware folks, not by Gentoo. Sorry.
The fix for this issue is to add the following to the kernel boot parameters: notsc noapic nolapic udev acpi=off Once this is done the clock will no longer drift.
