Time running fast after upgrading to PVE 2 final

[stuntshell]

Today after upgrading my cluster to the final release, one of the virtual machines is having the time running too fast.
This is a RedHat 5.5 and time/localzone is set correct. This was working fine before the upgrade.

I have tried a couple of different solutions, but none have worked:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
I tried:
kvm-clock
pit
tsc
jiffies

I also tried setting the different parameters in grub menu.lst and reboot.

Any help would be appreciated.

 

[fandert]

I have the same problem on my two Windows Guests (1x Windows 2008 Server R2 and 1x Windows 7 x64), the clock is about 5mins+ faster. On two Linux Guests i have a delay on the Guest which is 4-6secs.

The Time on the Host is correct.

I tried the "no-kvm-pit-reinjection"-Paramenter on the Windows7 Guest, but the problem still exists.

Thanks in advance.

Regards,
f.

 

[e100]

I had a VM with the same issue, I turned of ACPI in the VM config, stopped the VM and started it, problem went away.

 

[fandert]

With deactivated ACPI i can't boot anymore:

https://forums.virtualbox.org/viewtopic.php?f=2&t=37628

 

[spirit]

Hi,
for windows vm, are you sure to have choose windows vm type ? (just to be sure

also could you check in monitor that you have:

#info qtree

line ->
dev: mc146818rtc, id ""
dev-prop: lost_tick_policy = slew


for linux vm this is strange with kvm-clock you are normally always synced. (but maybe redhat 5.5 doesn't have kvm-clock ?
could you provide
cat /sys/devices/system/clocksource/clocksource0/available_clocksource from your redhat 5.5 ?

 

[fandert]

Hi,
for windows vm, are you sure to have choose windows vm type ? (just to be sure

also could you check in monitor that you have:

#info qtree

line ->
dev: mc146818rtc, id ""
dev-prop: lost_tick_policy = slew

it's "Microsoft Windows 7/2008r2 (win7)". Time was correct with PVE 1.9, i have this problem since the upgrade to 2.0.

The Parameter is correct.

Any other ideas?

 

[spirit]

could your try
"bcdedit /set {default} useplatformclock true" in your windows guest then reboot.

Reference:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/chap-Virtualization_Host_Configuration_and_Guest_Installation_Guide-KVM_guest_timing_management.html

 

[fandert]

could your try
"bcdedit /set {default} useplatformclock true" in your windows guest then reboot.

Reference:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/chap-Virtualization_Host_Configuration_and_Guest_Installation_Guide-KVM_guest_timing_management.html

still the same issue

Next week i will setup a new pve-host with 2.0-from-scratch and attach the guest there to check if there's the same problem.

Maybe there's another option...

Thanks in advance!

 

[spirit]

you could try to add this to your vm config:

args: -machine pc,kernel_irqchip=on

note that not yet officialy supported by proxmox,.

 

[ybilgili]

Have a look at this, it worked for me:

http://pve.proxmox.com/pipermail/pve-user/2012-April/003606.html

 

[e100]

I wonder if some of these time drift issues are caused by certain CPUs since not everyone has these problems.
What CPU do you use that has time drift issues?

 

[ybilgili]

I wonder if some of these time drift issues are caused by certain CPUs since not everyone has these problems.
What CPU do you use that has time drift issues?

Mine is E5620 @ 2.40 GHz

 

[spirit]

Seem to be related to hpet timer (default timer in win7/2008),
as hpet doesn't have timedrift compensation.
I'll do more investigation.

 

[e100]

I have a Win 2008 R2 VM running on 2.0, did nothing special and its time is not drifting.
In the config file it has: ostype: win7

Had an old Centos KVM VM, time was about 2x faster than real time on 2.0 Release. Disabled ACPI for it and now it works fine.
This was not an issue during RC1, only became an issue after the release and I upgraded.
Something changed in the last update to cause this.

Both VMs running on the same hardware:
model name : Intel(R) Xeon(R) CPU W3680 @ 3.33GHz

 

[fandert]

Have a look at this, it worked for me:

http://pve.proxmox.com/pipermail/pve-user/2012-April/003606.html

this solved the problem on both windows-guests, thank you!!!!

 

[stuntshell]

This solved my problem, thank you!

args: -no-hpet -no-kvm-pit-reinjection

 

[totalimpact]

i see

I am looking in /etc/pve/qemu-server/vmid.conf
and just append args: -no-hpet -no-kvm-pit-reinjection at the bottom

seems to have put my clock back to normal now.

 

[spirit]

Hi, thanks for debug,these args will be the default for coming qemu-server packages.
(The bug is that hpet timer don't support timedrift compensation, so we need to disabled it as winvista,7,2008 use hpet).


e100:

what's is your clocksource of your old centos ?
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

 

[e100]

e100:

what's is your clocksource of your old centos ?

With ACPI off dmesg says:

Using tsc for high-res timesource

I believe it was using hpet with ACPI enabled.

The odd thing is my windows VMs do not seem to have an issue with time and I've not disabled hpet on them.

 

[spirit]

The problem with hpet is it cannot do time compensation.

for old centos (with no kvm-clock available),
here the redhat recommendations: (depend if host is intel or amd)

http://docs.redhat.com/docs/en-US/R...lation_Guide-KVM_guest_timing_management.html