Bug 742736 - Use rtc tickpolicy catchup by default for windows guests
Summary: Use rtc tickpolicy catchup by default for windows guests
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python-virtinst
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Keywords:
: 767188 (view as bug list)
Depends On:
Blocks: 748554
TreeView+ depends on / blocked
 
Reported: 2011-10-02 09:34 UTC by Dor Laor
Modified: 2013-01-09 21:21 UTC (History)
10 users (show)

(edit)
Cause:
virt-install was not specifying any clock policy for windows guests.

Consequence:
windows guest time would skew from host time

Fix:
virt-install specifies the tickpolicy 'catchup' for windows guests.


Result:
windows guest time is less likely to skew
Clone Of:
(edit)
Last Closed: 2011-12-06 16:17:27 UTC


Attachments (Terms of Use)
Use clock timer mode 'catchup' for windows guests (6.19 KB, text/plain)
2011-10-18 14:50 UTC, Cole Robinson
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1643 normal SHIPPED_LIVE python-virtinst bug fix and enhancement update 2011-12-06 00:50:36 UTC

Description Dor Laor 2011-10-02 09:34:11 UTC
Description of problem:
If the above is not the default, windows guest will drift.

How reproducible:
Run windows guest (especially with winXP multimedia playing) and create load on the host and notice time drift.

Expected results:
No drift should be found.

Comment 1 Dor Laor 2011-10-02 09:34:42 UTC
According to Daniel we should have this:
  <clock offset="localtime">
     <timer name="rtc" tickpolicy="catchup">
  </clock>

Comment 2 Dor Laor 2011-10-05 09:25:04 UTC
It's fine to do it for all guests.

Old rhel5 hypervisor info (which is still valid w/ interface changes):
http://cleo.tlv.redhat.com/qumrawiki/KVM/TimeKeeping

Comment 3 Cole Robinson 2011-10-13 17:59:41 UTC
Again I have to ask, if it's fine to do it for all guests, why isn't this the default at the qemu level?

Specifically what OS need this to behave properly? Just WinXP? All windows (even win7)?

Comment 4 Dor Laor 2011-10-16 09:31:10 UTC
(In reply to comment #3)
> Again I have to ask, if it's fine to do it for all guests, why isn't this the
> default at the qemu level?

It shouldn't be set for all the guests but for most, nothing bad will happen if it exists (apart from rhel3). That's why we don't do it blindly w/ qemu (in addition to ignorant upstream qemu community w.r.t non x86) 

> 
> Specifically what OS need this to behave properly? Just WinXP? All windows
> (even win7)?

All windows flavors

Comment 7 Cole Robinson 2011-10-18 14:50:43 UTC
Created attachment 528826 [details]
Use clock timer mode 'catchup' for windows guests

Not a proper fix for upstream inclusion since that requires a bit more code than is worth backporting, but this should solve our issues for RHEL6.

Comment 9 Cole Robinson 2011-10-18 17:10:43 UTC
Fixed in python-virtinst-0.600.0-5.el6

Comment 11 Huming Jiang 2011-10-20 02:29:45 UTC
Reproduced with the following package:
python-virtinst-0.600.0-3.el6.noarch

Verified with 
kernel-2.6.32-197.el6.x86_64
qemu-kvm-0.12.1.2-2.192.el6.x86_64
libvirt-0.9.4-19.el6.x86_64
python-virtinst-0.600.0-5.el6.noarch
virt-manager-0.9.0-7.el6.x86_64

step:
1. Download a window2008 image from http://fileshare.englab.nay.redhat.com/pub/section3/libvirtmanual/Windows_KVM_images/win2008r2-64.qcow2
2. #virt-manager
3. Create a new guest w08 use the above image with the following steps:
   Create a new guest-> name is w08;import existing disk image -> select the downloaded win2008 image; os is windows; versions is microsoft windows server 2008;->
   Leave other configure default.
4. Run the guest, log into the guest ,found time is almost same with host.
5. use command #iozone -a to create load on host, and found guest's time is also almost same with host.
6. #virsh dumpxml w08
...
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
  </clock>
...
7. # ps -aef | grep qemu
qemu     22784     1  7 18:05 ?        00:01:38 /usr/libexec/qemu-kvm -S -M rhel6.2.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name xp -uuid ffafeb4c-df29-01c5-1e7e-78f58dbc2759 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/xp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-shutdown -drive file=/var/lib/libvirt/images/xp.img,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:3c:b2:ef,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:0 -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4

8. Check other windows guest; such as xp, win03, win7. All of them are OK

So move the status of this bug to 'verified'.

Comment 12 Cole Robinson 2011-11-07 17:28:59 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause:
virt-install was not specifying any clock policy for windows guests.

Consequence:
windows guest time would skew from host time

Fix:
virt-install specifies the tickpolicy 'catchup' for windows guests.


Result:
windows guest time is less likely to skew

Comment 13 errata-xmlrpc 2011-12-06 16:17:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1643.html

Comment 14 Cole Robinson 2012-02-03 20:12:33 UTC
*** Bug 767188 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.