locked
Berserk clock on Windows 7 VM under Hyper-V after installation of Windows 10 1803 on host RRS feed

  • Question

  • This is really a Virtualization with Windows 10 question but:

    After my Windows 10 host system decided it was time to install Windows 10 1803, my Hyper-V Windows 7 VM is running about 5 times normal speed.  The stupid spinney thing spins way too fast and many automatic services, like Windows Time, fail to start because of timeout.  After I start Windows time, the clock runs really fast for 4-5 seconds, then sets itself back 20 seconds to stay in sync.  Turn off windows time and it runs away at top speed.

    Has anyone else experienced this? Is there a fix in Hyper-V for it? Or on the client OS?

    Thursday, May 10, 2018 2:18 AM

Answers

  • Try to activate processor compatibility mode in VM settings.
    Wednesday, June 13, 2018 1:52 PM

All replies

  • Hi Geir Lanesskog,

    Check the link below about Hyper-V Time Synchronization Doesn't Correct the System Clock in the Virtual Machine if it is more than 5 Seconds ahead of the Host Clock.

    https://support.microsoft.com/en-sg/help/2618634/hyper-v-time-synchronization-doesn-t-correct-the-system-clock-in-the-v

    Hope it will be helpful to you


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

    Friday, May 11, 2018 9:06 AM
  • I also tried all steps indicated by Carl Fan (above) and the time issue is still not resolved.
    Tuesday, May 22, 2018 1:34 AM
  • That didn't help.

    Still running really fast, by the time sync actually works wonce the time service starts. It's just that the clock speeds.  It's actually faster than I thought 7.5 seconds to run a minute.  But once the time service gets started, it stays within 5-6 seconds.  It's just that the machine doesn't work well like this. Anything with a timeout tends to fail and don't even think about trying to double-click that fast.

    Basically unusable.

    Wednesday, May 23, 2018 2:31 AM
  • We are seeing the same thing on Windows 7 Hyper-V Virtual machines on an 1803 Host. The clock gains a minute in the VM per 11 seconds in real time is what we are seeing, and this is with both Windows 7 x86 and Windows 7 x64 guest OS.

    Thursday, May 24, 2018 12:28 PM
  • Confirmed also affecting server 2008 R2 guests on a server 2016 (1803) host.

    Worth noting, a freshly-rolled 08 R2 SP1 guest on the same host did not immediately present the issue.  Only after a few rounds of windows updates (on the guest) did the issue present.  I'm attempting to narrow down the magic update(s) now.

    Wednesday, May 30, 2018 2:24 AM
  • I am seeing the same thing. The VM worked fine for years without a problem and only after the Windows 10 1803 update did this problem occur. Exact same symptoms.

    This also happens on a legacy Windows XP virtual machine that also had run fine for years.

    Friday, June 1, 2018 11:28 PM
  • Same problem here.  Hyper-V Gen1 VM on 1803 host.....freshly installed copy of Win7 that we just fully patched. Clock runs super fast and the GUI is sped up as well.

    Saturday, June 9, 2018 5:09 PM
  • Applying June patches to host and VM didn't help at all. Still broken, even after a couple of extra shutdown/restarts to be sure.
    Wednesday, June 13, 2018 2:57 AM
  • Try to activate processor compatibility mode in VM settings.
    Wednesday, June 13, 2018 1:52 PM
  • I thought I tried processor compatibility before the last round of patches, but maybe not thoroughly.  It works now!

    But I was a bad troubleshooter and made two changes:

    

    And NUMA: 

    Use Hardware topology.  The VM was originally created on a 8 core machine and is now on a 12 core.  Never a problem earlier.  But now?

    Anyway, solve for me. For now.

    Thursday, June 14, 2018 1:59 AM
  • I am seeing the same thing. The VM worked fine for years without a problem and only after the Windows 10 1803 update did this problem occur. Exact same symptoms.

    This also happens on a legacy Windows XP virtual machine that also had run fine for years.

    Were you successful in getting the Windows XP VM to operate normally?  I have a Windows 7 VM that is running normally, but the Windows XP VM has the same clock / gui issue, even after selecting processor compatibility. 

    Wednesday, July 25, 2018 12:27 PM
  • I was able to get the Windows XP VM running normaly and the Processor Compatibility was indeed the issue.  However, I am certain I selected this before in the GUI (without any luck). 

    I ended up using powershell (as administrator) to toggle the option off and back on, which seemed to resolve the issue.

    Set-VMProcessor (vm name) -CompatibilityForMigrationEnabled $true

    I will note that I also toggled the -ExposeVirtualizationExtensions and -CompatibilityForOlderOperatingSystemsEnabled (both to false, then to true) along with the -CompatibilityForMigrationEnabled

    Hope this helps someone else!


    • Proposed as answer by ErnestoBernabe Thursday, December 6, 2018 6:11 PM
    Wednesday, July 25, 2018 8:02 PM
  • Thanks mrbenjamine!  No, I had not solved the problem with the Windows XP machine, but after carefully following your post it is now working properly.  I appreciate your help!
    Wednesday, August 1, 2018 6:20 PM
  • mrbenjamine20, THANK YOU VERY MUCH!

    For resolution of problem with WinXP (SP2) enough execute in powershell the following command:

    Set-VMProcessor "name-of-vm" -ExposeVirtualizationExtensions $true

    And timer begin work correctly.

    Thank you again!

    • Proposed as answer by Swaffy2x4b Tuesday, August 28, 2018 11:57 AM
    Tuesday, August 28, 2018 5:08 AM
  • Does anyone knows if this is fixed in 1809 ?
    Wednesday, October 3, 2018 5:09 PM
  • This worked for me.
    Thursday, December 6, 2018 6:15 PM
  • This worked for me on my Windows 7 Enterprise 32bit Hyper V VM...Thank you very much !!

    Set-VMProcessor "name-of-vm" -ExposeVirtualizationExtensions $true


    • Edited by mplagman Friday, February 8, 2019 6:23 PM
    Friday, February 8, 2019 6:22 PM