none
time source: Free running System Clock on domain host and VMs

    Question

  • Have a situation...

    1. domain members - host and vms are 20 min ahead of  logon DC.

    2. logon DC is on different host of different site and syncs correctly with Forests top DC.

    3. time sync with the host in Integr Services is unchecked for VMs

    I guess the above info indicates that it is obviously not a hyper-V problem.

    I decided to ask on this forum because saw something similar in Hyper-v discussions where enabling and disabling again VM time sync with a host fixed the issue.

    My first VM that was fixed just by doing that. After multiple reboots it chose logon server as a time source and sure right time.

    Unfortunately, the other VM is not fixed by doing that... and yes host is out of right time.

    Any suggestions what it could be... could it be Hyper-V related or just AD problem?

    Thanks.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis


    • Edited by pob579 Thursday, March 16, 2017 3:37 PM
    Thursday, March 16, 2017 3:36 PM

All replies

  • I never disable the time service integration services on my VMs and I never have an issue with my VMs keeping proper time.  By leaving the time integration active, VMs take the time of the physical host when they boot.  When running, if joined to the domain, they sync their time to the PDC.

    . : | : . : | : . tim

    Friday, March 17, 2017 1:44 AM
  • Hi,

    According to your description, my understanding is that VM host(member server in domain) and guest VMs on this VM host are 20 minutes ahead.

    I would recommend to correct the host device time first, and select the option to sync VMs time with host device. 

    Please reference - Troubleshooting Windows Time Service Problems – and check to see if it would be helpful:
    https://msdn.microsoft.com/en-us/library/bb727060.aspx

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, March 17, 2017 9:49 AM
    Moderator
  • 1. for the near past all what I saw on the web was the recommendation to disable sync with the host, especially on DCs.  Here is one of them where most of the people do disable it ...

    https://community.spiceworks.com/topic/477104-do-you-disable-the-time-syncronization-service-in-hyper-v

    "If your DC is an authoritative time server, all of your servers, including the Hyper-V hosts and VM's should all use your DC as the authoritative time server to sync their time.  As a result, I would disable the "Time Synchronization" feature in the settings of each of your VM's"

    "You need to disable the time sync if your hyper-v hosts are domain members. If you don't it creates a loop between the DC and the hyper-v host forcing clocks to keep jumping forward. "

    etc... one provides MS link with the recommendation to do it, another link for not doing it...

    2. the goal of my question is not to start arguing about enabling/disabling time sync... but try to find and eliminate the thing that happened after 7 years of server existence. There are still ten 2008 R2 Hyper-V hosts on remote sites with the same configuration. Time sync is disabled on all VMs. Because this was a cure for fixing time sync issue couple of years ago. Personally I don't think that if VMs are domain members they absolutely don't need to sync with the host potentially with a "dead" CMOS battery.

    3. back to the issue... I didn't emphasized in my initial post the problem mentioned in the subject of  the tread, when checked w32tm /query /status, source was showing:

    Free-running System Clock

    so my first question was AD issue. But not, logon server- the DC is on different site and provides accurate time to other 10 hosts and VMs.

    Sure it is not easy to narrow down why it happen. This what was done.

    1. enabled and disabled time sync on VM1 after reboot it corrected time and shows right SOURCE - dc.domain_name

    2. it didn't help for VM2.

    3. LAST TEST:

    a) changed the time on host in Windows and reboot the host.

    The result:

    Source on host shows: Local CMOS Clock and shows right time (that I corrected in Windows)

    Source on VM2 shows: Local CMOS Clock and shows right time

    Source on VM1 shows: logonDC.domain_name   that was fixed after enabling/disabling sync on VM.

    Important moment:

    VM2 has no TIME sync enabled

    NOW, I can ask myself a question :

    why the VM2 with no time sync enabled and wrong time before host reboot shows now right time. Looks like it took it from the host because it not shows time server (DC) name

    I guess that this behavior clearly indicates Hyper-V issue/glitch.

    My decision for now to not enable sync on VMs (just cannot rely on old host's CMOS battery).

    Will just try to register the time source pointing to LOGON Server name on host and VM2.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis


    • Edited by pob579 Friday, March 17, 2017 3:14 PM correction
    Friday, March 17, 2017 12:47 PM
  • finally to fix the issue of loosing time sync with DC, I run the following command:
    w32tm /config /syncfromflags:domhier /update
    

    And then stop and restart the time service by running:

    net stop w32time && net start w32time
    The Hyper-V weird behavior looks like not explainable in my situation.

    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Friday, March 17, 2017 1:16 PM
  • Hi,

    Thank you for taking the time to update the result. Your detail sharing might be helpful for other people who has the similar problem.

    If there is anything else we can do for you, please feel free to post in the forum.

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, March 21, 2017 7:23 AM
    Moderator