Bug 706884

Summary:	W2K3 KVM guest clock drift since RHEL6.1 kernel-2.6.32-131.0.15.el6.x86_64
Product:	Red Hat Enterprise Linux 6	Reporter:	nh
Component:	kernel	Assignee:	Gleb Natapov <gleb>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Red Hat Kernel QE team <kernel-qe>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.1	CC:	knoel, riel, sforsber, syeghiay, tburke, tis
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-13 09:32:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	767187

Description nh 2011-05-23 11:02:44 UTC

Description of problem:
Since updated to RHEL-6.1 and kernel-2.6.32-131.0.15.el6.x86_64 W2K3 32Bit KVM guests clock is not accurate anymore (slow by 30 minutes per 24 hours).
Adding /usepmtimer to boot.ini did not help btw.

Hypervisor Hardware is:
-HP ProLiant DL370 G6
-Intel(R) Xeon(R) CPU X5550 @ 2.67GHz
-constant_tsc CPU flag is present
-any kind of cstate or power management handling disabled in BIOS

Starting with RHEL-6.0 release it was working fine with the following kernel releases:
kernel-2.6.32-71.el6.x86_64
kernel-2.6.32-71.14.1.el6.x86_64
kernel-2.6.32-71.18.1.el6.x86_64

Interesting enough: The clock is working 100% correct if using RHEL-6.1 and only boot with latest RHEL-6.0 kernel-2.6.32-71.18.1.el6.x86_64.
The issue only occurs with RHEL-6.1 release kernel (2.6.32-131.0.15.el6).

Version-Release number of selected component (if applicable):
-RHEL-6.1 x86_64
-kernel-2.6.32-131.0.15.el6.x86_64
-qemu-kvm-0.12.1.2-2.160.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. Install and configure RHEL-6.1 as KVM Hypervisor
2. Install W2K3 32bit guest system
3. Wait and see W2K3 system-clock time going slower than Hypervisor's clock

Actual results:
W2K3 32Bit KVM guests clock is ~30 minutes per 24 hours slow compared to correct Hypervisor's clock.

Expected results:
Time drift shouldnt occur (as up to kernel-2.6.32-71.18.1.el6.x86_64).

Additional info:
Using RHEL-6.1 with latest RHEL-6.0 Errata kernel-2.6.32-71.18.1.el6.x86_64 is workarounding this issue.

Comment 2 RHEL Program Management 2011-10-07 15:36:10 UTC

Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 3 Dor Laor 2011-11-14 08:34:14 UTC

Can you please provide the qemu command line and libvirt's xml setting of that VM? The clock definitions should be like the following:

<clock offset="localtime">   (or utc for Linux)
     <timer name="rtc" tickpolicy="catchup"/>
     <timer name="pit" tickpolicy="delay"/>
</clock>

Comment 4 nh 2011-11-16 20:38:50 UTC

In the meanwhile the Hypervisor is running RHEL-6.1:
kernel-2.6.32-131.17.1.el6.x86_64
qemu-kvm-0.12.1.2-2.160.el6_1.8.x86_64

The guest system is running W2K8-R2.

The xml setting is as you stated above and the corresponding qemu command line was taken from /var/log/libvirt/qemu/ts3.log and looks like the following:

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 4096 -smp 2,sockets=2,cores=1,threads=1 -name ts3 -uuid 9db552e0-4bb2-4cb6-5612-814ae164d3e0 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ts3.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-kvm-pit-reinjection -drive file=/var/lib/libvirt/images/pool1/ts3.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=writethrough -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:cd:fd:b4,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4

This combination is running quite stable regarding Windows clock.

The W2K3 System we have moved to a RHEL-5.7 Hypervisor where the Windows clock is running quite stable as well, so I cannot provide further information regarding a combination of RHEL-6.1 HV + W2K3 guest - sorry.

Comment 5 Gleb Natapov 2011-12-12 18:16:26 UTC

(In reply to comment #4)
> In the meanwhile the Hypervisor is running RHEL-6.1:
> kernel-2.6.32-131.17.1.el6.x86_64
> qemu-kvm-0.12.1.2-2.160.el6_1.8.x86_64
> 
> The guest system is running W2K8-R2.
> 
> The xml setting is as you stated above and the corresponding qemu command line
> was taken from /var/log/libvirt/qemu/ts3.log and looks like the following:
> 
> This combination is running quite stable regarding Windows clock.

Since, as you say, this guest has no time drift problem its information is not useful to solve the bug.

> 
> The W2K3 System we have moved to a RHEL-5.7 Hypervisor where the Windows clock
> is running quite stable as well, so I cannot provide further information
> regarding a combination of RHEL-6.1 HV + W2K3 guest - sorry.

Without further information I will have to close this bug as INSUFFICIENT_DATA.