Some Windows VMs start with incorrect clock

S

SteveITS

Active Member
Proxmox Subscriber
Feb 6, 2025
249
85
28
We have a handful of Windows Server VMs in our cluster (just migrated to Proxmox). I've noticed when some are shut down, they start with the clock 5 hours in the past. If I log in and toggle the option to have Windows sync the clock, it does so immediately.

One that does not need a manual sync is using q35 and SeaBIOS but is Server 2022. Two that I know do need a manual clock fix are using i440fx and SeaBIOS, and are Server 2019.

All of those are set with "use local time for RTC" as "Default (Enabled for Windows)." Is q35 required for that to work? Or, why are some not booting up with the correct time?
 
Last edited:
is the type of the VM set to Windows and there is a switch for the clock settings as well.

It is well known that Microsoft does not follow the host clock because early DOS did not have support for time zones hence the host clock on Windows runs at local time rather than GMT.

In your VM settings:
Set "Use local time for RTC" to default and "OS Type" to Windows.

Also I would recommend moving towards UEFI/Q35 (although on Windows you’d have to be careful with disk conversion and drivers for existing systems)
 
Hi, hence my concern. Both are set to the correct Windows version selection, and default time as noted above. These were imported but so was the third. The BIOS and the OS version setting are the only differences AFAIK aside from amount of RAM and for one, number of cores.

I guess I can try the BIOS setting, but it seems silly the RTC setting is dependent on that without it being a bug.
 
Changing to q35 did not help, nor did setting "use local time for RTC" to Yes.

I can resolve by toggling this off and on:
1746765600444.png
...to get:
1746765616797.png

...but of course that's a problem if no one actually does that after a VM shutdown.
 
SteveITS said:
Wondering if this thread means no one is seeing this, or no one has a solution. :-/
Click to expand...
It likely means that most people are not experiencing the same issue, and as such, it is highly specific to your environment/configuration.
SteveITS said:
Bumping now that I'm finally tied to a subscription.
Click to expand...
That would mean that you can open a support ticket with PVE by supplying well organized and detailed report. If/when it gets solved - come back and update the thread! I'd be interested to hear back.

Good luck

PS if it is 5 hours on the dot - is this a timezone issue? Have you checked Windows Event log - it normally has some data on time sync. Windows also may have a registry option you can add to enable debug for the time sync.
Usually Windows syncs time with AD, any logs on that side?

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Nobody else is having this problem.

Few things to check:
Again, check the setting to make sure it is set to Windows and make sure to completely turn off the VM when you make changes like that.

Second would be to check time zones both on your Proxmox and Windows side.

You can also see what Windows uses as a time source:

w32tm /query /status

In some AD situations you may get your time from a “faulty” NTP server.
 
I expect it is exactly a time zone issue with the RTC moving the VM clock backwards. It just didn't happen to all VMs. (in my experience clocks being off by exactly hour intervals is virtually guaranteed to be some sort of time zone issue)

These are standalone servers, no AD. VM is still set to Windows. :)

My next approach was to experiment with a task to run w32tm on startup.

> w32tm /query /status

OK, ran that, and found the two problem VMs have their W32Time service set to Manual start, so the service is not running and the command fails. Not sure why these two are different. Or why it wasn't a problem on the prior platform. Unless, literally, these VMs never actually turned off... I installed them from ISO myself. It's been 2.5 years so seems unlikely but maybe possible, since, you know, uptime.

I can't recall having to enable the time service on any other server I've installed over the years. Our procedure is to set a time server on the AD time source server. I found an article online that says Manual start is normal on a workgroup PC "since Windows 7, and Windows Server 2012 R2." So maybe it was always set to Auto on DCs. Of our Windows VMs, these are the middle two, age-wise, so I don't know why some are Auto and some are not. That same article also says Windows may set the service back to Manual/trigger by itself.

Perhaps the "set time automatically" checkbox starts and then stops the service. One would think it would check at boot though.

I will have to test a power down late some night, when I can, but that sure seems likely to be related. That might also imply the other VMs are booting up with the earlier clock and then immediately updating on their own.

Thanks. Needed a new set of eyes/brain.
 
Windows not being idempotent upon install or after some time running is not unsurprising, could be related to an update or something got corrupted in the single client 1980s database better known as the registry. Nothing to do with VMs, just poor software development.

My guess is that at one point your VM went out of sync with the CMOS clock your hypervisor had (Proxmox or something before). Unlike normal OS, Windows does a lot of shenanigans to get the clock to work the MSDOS way and emulate the ancient time APIs (eg time cannot go “backward” or stand still - good luck with that leap second), and if it goes off by a number of seconds in the wrong direction it just gives up and stops syncing time. According to Microsoft, this is not a bug, this is a feature.

There was someone on another forum about low level programming that noticed in a Windows VM on certain processors time could actually appear to “stand still” (subsequent calls to a precision time API returned the same time) causing major issues with timers.
 
I’ll have to watch these. The irony is they were powered down for a Proxmox VM hardware change, otherwise wouldn’t have been. And that’s when the time resets backwards, I could duplicate it.

Ain’t software fun…
 
It seems that service was the answer.

I shut one "problem" VM down, started it, the Windows pre-login screen showed the wrong (-5h) time, and by the time I logged in, the time had moved forward again to the correct time.

It still seems like "Use local time for RTC" set to Default or Yes should have it start with the correct time, but at least it is self-fixing now. Otherwise, with the wrong time, the MFA prompt fails, as well as other stuff.

Events with "time" from when I shut it down:

Code: 
Log Source : Service Control Manager
Log EventID : 7036
Log Time Generated : 5/29/2025 11:46:48 PM
Log Message : The Windows Time service entered the stopped state.

Log Source : Microsoft-Windows-Kernel-General
Log EventID : 1
Log Time Generated : 5/29/2025 11:46:48 PM
Log Message : The system time has changed to ‎2025‎-‎05‎-‎30T03:46:48.236454900Z from ‎2025‎-‎05‎-‎30T03:46:48.236424900Z.

Log Source : Microsoft-Windows-Kernel-General
Log EventID : 13
Log Time Generated : 5/29/2025 11:46:54 PM
Log Message : The operating system is shutting down at system time ‎2025‎-‎05‎-‎30T03:46:54.695392900Z.

Log Source : Microsoft-Windows-Kernel-General
Log EventID : 1
Log Time Generated : 5/29/2025 11:47:34 PM
Log Message : The system time has changed to ‎2025‎-‎05‎-‎30T03:47:34.357755600Z from ‎2025‎-‎05‎-‎30T03:47:34.356978900Z.

Log Source : Microsoft-Windows-Time-Service
Log EventID : 35
Log Time Generated : 5/29/2025 11:47:34 PM
Log Message : The time service is now synchronizing the system time with the time source time.windows.com,0x9 (ntp.m|0x9|0.0.0.0:123->168.61.215.74:123) with ref...

Log Source : Microsoft-Windows-Kernel-General
Log EventID : 1
Log Time Generated : 5/29/2025 11:47:34 PM
Log Message : The system time has changed to ‎2025‎-‎05‎-‎30T03:47:34.349855400Z from ‎2025‎-‎05‎-‎29T22:47:33.409650000Z.

(note the last is "from 05-29")
 
You must log in or register to reply here.
Top Bottom