Timesync on HyperV with CentOS 6.2

Question

I've got a CentOS VM (release 6.2) running under HyperV. I have integration services installed (part of base now), and CentOS shows the current clocksource is hyperv_clocksource, however my time in the VM is about 10 minutes fast after a week of uptime. My understanding of the new IC and plugable clocksource is that this shouldn't happen any more. Is there any additional configuration necessary to get the plugable clocksource to "work?"

I know there are plenty of links about setting kernel options to PIT and various stuff like that, but those all seem to pre-date the integrated clocksource support, and as I understand it shouldn't be needed anylonger. Nor should ntpd nor adjtimex.

Edit: Was running 3.2 of IC (what ships w/Centos 6.2), upgraded to 3.3 today, machine has been up for 1 hour 22 minutes and clock is already 5 seconds fast. So I'm now running the latest IC and still have the same problem.

Yes, the time is *fast* not slow. Which is even odder as the typical VM clock issue is the loss of time, not the gain of time. — WaldenL, Jun 25 '12 at 16:11
if you do a powershell get-winevent -provider Microsoft-Windows-Hyper-V-Integration-TimeSync | select message | select-string "servername" do you see any time sync errors — tony roth, Jul 02 '12 at 18:19
Nevermind messages about time-sync errors, there are no messages for that provider at all. There are other Hyper-V messages, but none for TimeSync. — WaldenL, Jul 03 '12 at 13:40

score 3 · Answer 1 · answered Jun 29 '12 at 20:00

I've had this issue in the past and corrected it by tweaking the startup switches (notsc divider=10) and ntp settings:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-164.6.1.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=/dev/VolGroup00/LogVol00 hda=noprobe hdb=noprobe notsc divider=10
    initrd /initrd-2.6.18-164.6.1.el5.img
title CentOS (2.6.18-164.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/VolGroup00/LogVol00
    initrd /initrd-2.6.18-164.el5.img

Sample ntp.conf:

tinker panic 0
restrict 127.0.0.1
restrict default kod nomodify notrap
server 0.vmware.pool.ntp.org
server 1.vmware.pool.ntp.org
server 2.vmware.pool.ntp.org
driftfile /var/lib/ntp/drift

Source:

Correcting Linux Clock Drift on Hyper-V on Server 2008 R2
http://hardanswers.net/correct-clock-drift-in-centos-hyper-v

This might work. MS's official stance is to install/enable integration features including time sync, and disable any in-VM time daemons (ntpd). — Chris S, Jun 29 '12 at 20:16
[VMWare](http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427) recommends this `divider=10` in many Linux-constellations, too. — Nils, Jun 30 '12 at 21:16
Sorry for the downvote, but these are precisely the tweaks that aren't supposed to be needed with the plugable timesource in the new integration components. — WaldenL, Jul 01 '12 at 10:08

score 3 · Answer 2 · edited Apr 13 '17 at 12:14

Hyper-V Linux guest clock drift under load is sadly quite common (clock drift in unsynchronised VMs is somewhat unavoidable). See Linux clock loses 10 minutes every week and Hyper-V Machine drifts time all over, even with NTP for other posts talking about it. Anecdotal evidence I've seen says the following:

The Hyper-V host's clock is only used to set the Linux guest's clock on startup with current kernels (up to and including at least mainline 3.16 kernels or integration services 3.5). If you are using such Linux kernels, it does not matter what options you set in Hyper-V Manager nor will it matter that current_clocksource is hyperv_clocksource - your clock will drift after boot and won't be corrected unless you run one of the synchronisation programs below. There is a lot of complicated Windows oriented and conflicting information surrounding this topic and oft repeated terms like "pluggable time source" to understand.
ntpd is unable to correct the amount drift that can occur in a Linux Hyper-V guest and you will either have to use regular brute force ntpdate synchronisations (bad) or an ntp service such as chrony (better) to correct large clock drifts.

longneck · Answer 3 · 2012-06-30T01:31:31.453

2

First, check if hyper-v is detecting the integration services. The only way i know how is using system center virtual machine manager, but i assume there must be a way using hyper-v's mmc.

Also, I have seen this happen when clock sync is disabled in the VM configuration. Why the clock runs faster is beyond me. I've attached a screenshot of the vm configuration for your reference. enter image description here

edited Jun 30 '12 at 01:31

answered Jun 29 '12 at 19:19

longneck

22,793
4
50
84

Yes, all services are enabled. – WaldenL Jul 01 '12 at 10:08
does hyper-v report that it has detected the integration services? – longneck Jul 01 '12 at 12:39
Interesting question, not sure how to tell. They show started in the guest, and I _assume_ they wouldn't do that if they hadn't communicated with the host, but I can't say for sure. I don't have scvmm so I'm not sure ow to tell either. – WaldenL Jul 01 '12 at 14:48
When you look at the vm in the mmc, does it say heartbeat ok at the bottom? That would indicate that at least the heartbeat service is communicating. – longneck Jul 01 '12 at 16:12
It does say "Heartbeat: OK", so it seems at least the communications channel is open. – WaldenL Jul 02 '12 at 14:55

Timesync on HyperV with CentOS 6.2

3 Answers3

Linked