You just spun up a Windows VM in Proxmox VE, logged in, and the clock in the taskbar is off. Not by a minute or two — by five hours, or eight, or whatever your UTC offset happens to be. You fix it manually, reboot the VM, and it's wrong again.
This is one of the most common "wait, what?" moments for anyone new to Proxmox coming from VMware or bare-metal Windows. The good news: it's not a bug, and it's not your NTP server. It's a mismatch between how Windows expects its hardware clock to behave and how Proxmox has it configured for that particular VM.
Once you understand the setting involved, the fix takes about thirty seconds.
What You Will Learn
- Why Windows VMs show the wrong time in Proxmox VE even when the host clock is correct
- What the RTC (real-time clock) and "local time" setting actually do
- How to check and change this setting from the GUI and from the shell
- Why the fix sometimes doesn't seem to "stick," and what actually needs to happen for it to apply
- A registry-based workaround for people who run mixed Windows and Linux VMs on a host set to UTC
What Is This Feature?
Every virtual machine has an emulated motherboard, and every motherboard has a battery-backed clock called the RTC, or real-time clock. When an operating system boots, it reads the RTC to figure out what time it is, before any network time sync has had a chance to run.
Here's the part that trips people up: Linux and Windows disagree about what "the time" on that clock actually means. Linux assumes the RTC stores UTC, and applies your configured time zone on top of it. Windows assumes the RTC already stores your local time, no translation needed.
Proxmox VE has a per-VM option to handle this called Use local time for RTC, which maps to a config key named localtime. When it's enabled, QEMU (the hypervisor engine behind every Proxmox VM) feeds the guest a clock value based on the Proxmox host's local time zone instead of UTC.
Proxmox is actually pretty good about this by default. If you pick a Windows OS type (like win10, win11, or win2022) when you create the VM, localtime gets set to 1 automatically. The wrong-clock problem almost always shows up when that didn't happen — usually because the OS type was left as l26 (Linux) or Other during creation.
Why Would You Use It?
You're not really "using a feature" here so much as making sure Proxmox and your guest OS agree on a very basic assumption. But it's worth understanding why the setting exists at all, instead of just flipping a switch and moving on.
If you skip this and just fix the clock by hand inside Windows, it'll drift back to being wrong on the next reboot, because you never touched the actual source of the problem: what value QEMU hands the guest at boot time. You'd be fighting the same battle every time the VM restarts.
Understanding the RTC setting also matters the moment you run a mixed environment — say, a Debian VM for a reverse proxy and a Windows Server VM for Active Directory on the same node. Each guest can have its own localtime value, so you don't have to pick one time convention for your whole host.
Prerequisites
- A working Proxmox VE 8.x or 9.x host with at least one Windows VM already created
- Shell access to the Proxmox host, either through the web-based Shell in the node view or SSH
- Permission to change VM configuration (the default
root@pamaccount has this; a delegated user needsVM.Config.Optionson the VM) - Your Proxmox host's time zone already set correctly (check with
timedatectl— if the host itself has the wrong zone, fixing the VM won't help)
You don't need to install anything extra for this. No guest agent, no additional packages.
Step-by-Step Tutorial
1. Confirm the host's time zone is actually right
Before touching the VM, open a shell on the Proxmox host and run:
timedatectlLook at the Time zone line. If it says UTC and you expected, say, America/Chicago, that's your real problem, and no VM-level setting will fix it. You can change it under Datacenter → Options → Time zone in the GUI, or with timedatectl set-timezone America/Chicago from the shell. Assuming the host zone is correct, move on.
2. Check the VM's current RTC setting
Find your VM's ID (the number shown in the left-hand tree, like 101 or 205), then run:
qm config 101 | grep -i localtimeIf you get no output at all, the option isn't explicitly set, which means Proxmox is falling back to whatever the ostype implies. Check that too:
qm config 101 | grep -i ostypeIf ostype shows l26, l24, or other on a VM that's actually running Windows, you've found the root cause.
3. Fix it from the GUI
In the Proxmox web interface, click your VM, go to Options, and find Use local time for RTC in the list. Double-click it (or select it and click Edit), and set it to Yes.
While you're on that Options tab, it's worth also correcting OS Type to match the actual Windows version installed, if it's wrong. That prevents the same confusion from resurfacing after a future clone or template rebuild.
4. Or fix it from the shell
If you'd rather script it or you're managing several VMs at once, the CLI equivalent is:
qm set 101 --localtime 1To go the other way — force UTC on a VM even though it's a Windows guest, which is occasionally useful in mixed environments — use:
qm set 101 --localtime 0And if you'd rather just remove the override and let Proxmox decide automatically based on ostype:
qm set 101 --delete localtime5. Fully stop and start the VM
This is the step people skip, and it's why the "fix" sometimes seems like it didn't work. The localtime value is read when QEMU launches the virtual machine process. A guest-side reboot, or even qm reboot 101, does not relaunch that process — it only resets the operating system inside an already-running QEMU instance. Pending config changes like this one apply only on the next full stop and start.
qm shutdown 101
qm start 101Give the shutdown a few seconds to complete cleanly (Windows can take 15–30 seconds to respond to an ACPI shutdown signal) before starting it back up. Once it boots, check the clock. It should be correct immediately, before Windows even reaches the login screen.
Commands Explained
| Command | What it does |
|---|---|
timedatectl | Shows the Proxmox host's current date, time, and configured time zone. |
qm config <vmid> | Prints the full configuration of a VM, including every option currently set. |
qm set <vmid> --localtime 1 | Tells QEMU to present the RTC to the guest using the host's local time zone instead of UTC. |
qm set <vmid> --localtime 0 | Forces UTC on the RTC, overriding the automatic Windows default. |
qm set <vmid> --delete localtime | Removes the manual override so the setting follows ostype again. |
qm shutdown <vmid> | Sends a clean ACPI shutdown request to the guest, ending the QEMU process once it powers off. |
qm start <vmid> | Launches a fresh QEMU process for the VM, picking up any pending configuration changes. |
Common Errors
The clock is off by an exact number of hours right after you build a new Windows VM. This is almost always a leftover ostype from the VM creation wizard. If you selected the wrong Windows version, or left it on a generic type, localtime never got enabled. Fix it with the steps above.
You changed the setting, but the clock is still wrong. Nine times out of ten, the VM was rebooted from inside the guest instead of being fully shut down and started from Proxmox. QEMU never re-read the new value because its process never restarted.
The clock is correct for a few seconds after boot, then jumps to a wrong value. This usually means Windows Time service reached out to an NTP source and got a bad reading, or the VM has no internet access and a stale scheduled sync fired anyway. Check with w32tm /query /status inside the guest.
Time is right in Windows but wrong in a Linux VM on the same host. That's expected if localtime got accidentally enabled on the Linux guest. Linux VMs should almost always have this set to 0, since the OS applies its own time zone on top of a UTC-based RTC.
Troubleshooting
If the clock is still wrong after a full stop and start, work through this in order:
- Re-run
qm config <vmid> | grep -i localtimeand confirm the value actually saved. A typo in the VMID during your earlierqm setcommand is a common way this silently fails to apply. - Re-check
timedatectlon the host. If someone changed the host's time zone after the VM was configured, the "local time" QEMU hands over will follow the new host zone, which might not be what you expect. - Inside the Windows guest, open Event Viewer and look under Applications and Services Logs → Microsoft → Windows → Time-Service → Operational for recent sync events. If Windows Time service is fighting your RTC value, you'll see it here.
- If the VM was cloned or restored from a backup, verify the clone actually inherited
localtime. Full clones copy the config, but if you built the template before settinglocaltime, every VM cloned from it inherits the same gap.
One thing that isn't a bug, even though it looks like one: right after you flip a Windows host from UTC to a named local zone (or vice versa) at the datacenter level, every Windows VM on it will show the wrong time until it's fully restarted. The RTC value is calculated at boot, not updated live.
Best Practices
Set the correct ostype at VM creation time, every time. It costs you nothing, and it means you'll never hit this problem to begin with — Proxmox handles localtime for you based on that single field.
Keep your Proxmox host's time zone accurate and stable. Changing it later ripples into every Windows VM that relies on "local time" being derived from the host.
If you build VM templates, fix the RTC setting on the template itself before you clone from it. It's much less annoying than fixing forty VMs one at a time after the fact.
For mixed fleets on a host pinned to UTC, consider the Windows-side registry workaround instead of juggling per-VM overrides: set HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal to a DWORD value of 1 inside the guest. That tells Windows to treat the RTC as UTC, matching Linux's expectation, without touching anything in Proxmox. It's a bit of a niche trick, and most homelab users will never need it — but it's the cleaner option if you're running a UTC host on purpose.
Install the QEMU Guest Agent while you're in there. It won't fix an initial RTC mismatch, but it makes clean shutdowns (like the one this fix depends on) faster and more reliable than waiting on a plain ACPI signal.
Frequently Asked Questions
Does this affect Linux VMs too?
The same localtime option exists for Linux guests, but it should almost always stay off. Linux expects UTC on the RTC and handles the local display itself.
Do I really need to restart the whole VM, or can I just reboot Windows?
You need a full stop and start from Proxmox. A reboot triggered inside Windows, or even qm reboot, doesn't relaunch the underlying QEMU process, so the new RTC value never gets read.
My clock is off by exactly one hour, not five or eight. Is this the same issue?
Probably not. A one-hour offset is more often a daylight saving time mismatch between the host and the guest than a UTC-versus-local RTC problem. Check that both are using the correct, current time zone rules.
Will installing the QEMU Guest Agent fix this automatically?
No. The guest agent handles things like clean shutdowns and IP reporting back to Proxmox, but it has no control over the RTC value QEMU presents at boot.
Can I keep my host on UTC and still have Windows show the correct local time?
Yes, using the registry-based RealTimeIsUniversal workaround described above. It's the standard approach for people who intentionally run their host clock in UTC.
Does cloning or restoring from backup preserve the RTC setting?
Yes, localtime is stored in the VM's configuration file, so a full clone or a backup restore keeps whatever value the source VM had.
Conclusion
A Windows VM with the wrong clock feels like it should be some deep networking or NTP issue, and that's usually where people start troubleshooting — checking DNS, checking the router, checking Windows Update. The actual cause is almost always this one small, easy-to-miss setting from the moment the VM was created.
Get the OS type right when you build the VM, and you'll likely never think about this again. If you're fixing an existing VM, flip localtime, do a real stop and start instead of a soft reboot, and the clock will be right from the very first second Windows comes up.