Hide Forgot
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.
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.
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>
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.
(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.