time drift in all guests

softlion

Active Member
Dec 10, 2009
63
0
26
[fixed] time drift in all W8K guests

EDIT: see fix at the bottom thread in my last post
----
REOPENED: I wrote too fast.
The problem is still there.
-----
EDIT: the following command fixed the problem.
For Windows 2008/R2 guests only (Windows 7 does not have any problem):
bcdedit /set {default} useplatformclock true
-----

Hi all,
I have a strange bug with qemu / proxmox.

On one server, there are 2 x64 kvm guests (win 2008 r2).
Both have a time drift of 1s/h (ie: after 6h the guest time is 6s less than the real time).
And if i reboot one of the guest, its time is 2s less than the host time ! (which is correclty sync with a ntp).
note: 1st has 1cpu 512Mo ram, 2nd has 4cpu 6Go ram. So not cpu dependant.

On a second server (same cpu/ram), with the same setup and a freshly installed guest, there is no time drift. The guest time is exactly the host time.

I've checked the conf files, they are the same.
Both pveversion -v and uname are the same:

pve-manager: 1.6-5 (pve-manager/1.6/5261)
running kernel: 2.6.35-1-pve
proxmox-ve-2.6.35: 1.6-7
qemu-server: 1.1-22
pve-firmware: 1.0-9
libpve-storage-perl: 1.0-14
vncterm: 0.9-2
vzctl: 3.0.24-1pve4
vzdump: 1.2-8
vzprocps: 2.0.11-1dso2
vzquota: 3.0.11-1dso1
pve-qemu-kvm: 0.12.5-2
ksm-control-daemon: 1.0-4

uname -a
Linux xxxx 2.6.35-1-pve #1 SMP Tue Oct 26 11:05:44 CEST 2010 x86_64

I've also tryed to add args: -no-kvm-pit-reinjection
No luck: still the 2s delta at boot time (I've not checked the drift though).

I've also tryed to add args: -rtc-td-hack
No luck.

I've also tryed to sync time with a ntp, the stop and restart a drifting vm.
After sync the time is perfectly synced. After stop/start the time is 2s late.

Ah, there is a difference.
On the drifting server, both vms are using qcow2 format. On the correct server, the vm is using raw format.
On one drifting vm, i converted all disks to raw. After start the time is still 2s late.

Ah there is another difference. drifting vms are both in driver testsigning mode.
I turned off test signing on one of the drifting vm and stopped started it.
still no luck.

Currently i've installed the ntp client service attached in the following post to get the time synced. If you have any idea how to fix ...
https://bugzilla.redhat.com/attachment.cgi?id=384566
 
Last edited:
I had a similar problem some time ago with PVE 1.5 and time drifts on Windows Machines within a domain to the max. value of 30 minutes.

HPET Emulation of Qemu was disabled.
After enabling it the problem vanished and the machines are since then in sync with the DC.

But a time drift with a value measured in only some seconds is really not that much :)
 
This is a very little timedrift. Very easy to correct. After investigation the problem on KVM, Xen, Microsoft and Vmware solutions I have come up with following:
- It can help to add a "/usepmtimer" flag on the virtual Windows 2003 servers. Maby something similar can solve problems on Windows 2008 R2 servers?
- Sync Windows servers against the Proxmox servers often. In my case I have set it to every 5 minute. Then even a tiny timeshift is corrected.
All the virtual host platforms have problems with timeshifts and ntp/wts is the only way to solve it.

The most bissare timeshift problem I experienced was when I upgraded the virtio network drivers on a Windows 2003 terminalserver. When over 10 users was logged on the server the time startet to run fast forward. Then after it had moved serveral minutes forward it started to run normally again. I solved the problem by downgrading to old 1.0 virtio network drivers. After that I have not dared to try upgrading working virtio drivers on the windows guest servers.
 
Last edited:
Hi again,
/usepmtimer is not available on windows 2008+.

I now know what is the cause of the time shift.
The time shift occurs only when at least 2 windows 2008 VMs are active on the same host. If one of them is stopped, no time shift occurs on the one which is running.

I said above that the shift was about 6s / 6H, well I removed the custom NTP client and the shift was 1mn per 30mn, much much higher !
I finally scheduled an NTP sync every 10 minutes, but this is not satisfying for the business.

HPET Emulation

I will search docs about this option that i do not know and post the results.

EDIT
I've added
args: -no-hpet
to the .conf file of both VMs and will post results tomorrow.
 
Last edited:
args: -no-hpet within the config file of the VM should disable the the High Precision Event Timer (HPET)

I'm not quite sure if is included in some versions of qemu-server and in others not.

Maybe your hardware needs to have this kind of clocksource....

I only noticed that in version 1.5 of Proxmox the HPET Emulation was disabled for Windows guests.
After upgrading to 2.6.32-2 and PVE 1.6 some time ago the problem with timedrifts vanished and HPET Emulation was enabled by default.

You can check if HPET is enabled by opening the QEMU monitor on the Proxmox Webinterface (or on the commandline of the host) and issuing "info hpet"
 
You can check if HPET is enabled by opening the QEMU monitor on the Proxmox Webinterface (or on the commandline of the host) and issuing "info hpet"

After checking, hpet is enabled on all guests where the flag -no-hpep is not set :=)
The 2008 vm with HPET disabled still has a very very small drift of 1s. But this is much better.

I've set up a 3rd guest, a Windows 7, with 2 cpu and hpet enabled.
No drift at all !
So it may be only Windows 2008 R2 related or cpu related (one has 4 cpu / the other 3 cpu).

bcdedit /set {default} USEPLATFORMCLOCK

I've set this on one of the windows with hpet enabled and let you know.
Thanks for the tip.


You can check if HPET is enabled by opening the QEMU monitor on the Proxmox Webinterface (or on the commandline of the host) and issuing "info hpet"

After checking, hpet is enabled on all guests where the flag -no-hpep is not set :=)
The 2008 vm with HPET disabled still has a very very small drift of 1s. But this is much better.

I've set up a 3rd guest, a Windows 7, with 2 cpu and hpet enabled.
No drift at all !
So it may be only Windows 2008 R2 related or cpu related (one has 4 cpu / the other 3 cpu).

bcdedit /set {default} USEPLATFORMCLOCK

I've set this on one of the windows with hpet enabled and let you know.
Thanks for the tip.

EDIT: the correct command is:
bcdedit /set {default} useplatformclock true

Enabling the use of the "UsePlatformClock" boot option within the Windows Boot Loader resolves the issue by forcing the operating system to use the HPET instead of the default TSC and thereby avoiding issues related to a Multi-Clock Domain (multi-node) server configuration.

bcdedit should now show:
Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Windows Server 2008 R2
locale en-US
inherit {bootloadersettings}
recoverysequence {bf694462-efcf-11df-8d00-f016d973c886}
recoveryenabled Yes
osdevice partition=C:
systemroot \Windows
resumeobject {bf694460-efcf-11df-8d00-f016d973c886}
nx OptOut
useplatformclock Yes

I'll let you know if it is better tomorrow.
 
Last edited:
EDIT: no it didn't worked :(
Drift: 5~15 seconds per hour.
The host time is perfect and not drifting at all.
I've set up a frequent NTP update.
---
It worked. I marked the thread as fixed.
Thanks you very much Halgeir !
 
Last edited:
Well I finally found a combinaison of flags which fix the time drift problem in all guests.

Add this to your /etc/qemu-server/xxx.conf :
args: -no-hpet -no-kvm-pit-reinjection

And in your windows 2008 R2 guest write this in an elevated command line then stop and start the guest (reboot is not sufficient):
bcdedit /set {default} useplatformclock true
 
I've tried to follow these instructions and while "bcdedit /set {default} useplatformclock true" works on Windows Server 2008 R2 guest OS's -- it does not work for Windows Server 2008.

I received the following error:
C:\Windows\system32>bcdedit /set {default} useplatformclock true
The element data type specified is not recognized, or does not apply to the
specified entry.
Run "bcdedit /?" for command line assistance.

Any idea why -- all the documentation I've seen indicates it should work on both platforms.
 
Grooverider, Did you find a solution to your problem? I also can't use this command on a Windows 2008 guest. However, it did work on my 2008 R1 guests.
 
Grooverider, Did you find a solution to your problem? I also can't use this command on a Windows 2008 guest. However, it did work on my 2008 R1 guests.

No command needed anymore in guests.
Upgrade host to Debian 6 and to proxmox 2.
Proxmox 2 sets the qemu options correctly.
And debian 6 is much more stable.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!