Bug 823372 - Time drift on windows guest after 3 days running on a stressed host
Time drift on windows guest after 3 days running on a stressed host
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Gleb Natapov
Virtualization Bugs
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-21 00:32 EDT by Qunfang Zhang
Modified: 2013-12-08 19:57 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-24 22:47:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
time drift log of windows guest (5.69 MB, text/plain)
2012-05-21 00:41 EDT, Qunfang Zhang
no flags Details

  None (edit)
Description Qunfang Zhang 2012-05-21 00:32:33 EDT
Description of problem:
I boot multiple vms on both intel and amd hosts (totally 1.5*p-mem and 3*p-cpu overcommit) , and let them run during a weekend. But When I check them on the Monday morning, there's -21 (AMD) and -37 (Intel) seconds time drift on the windows guest. There's no any application running inside guests except a script loop to check the system time every 15 seconds.

Here's the detail information for the hosts and guests:
Intel:
Host: 12G mem and 16 cpus
       cpu information please check the 'Additional info' of the bug report.
Guest: Running 20vms (including win2k8r2 guests and rhel6.3-64 guests)
       16vms have 1G v-mem and 2 vcpu
       4 vms have 512M v-mem and 4 vcpu

AMD:
Host: 8G mem and 4 cpu
      cpu information please check the 'Additional info' of the bug report.
Guest: Running 12 vms (6 win2k8r2 and 6 rhel6.3-64)
       each vm has 1G v-mem and 1 vcpu.


Version-Release number of selected component (if applicable):
2.6.32-272.el6.x86_64
qemu-kvm-0.12.1.2-2.294.el6.x86_64

How reproducible:
1/1 (running 3 days so far)

Steps to Reproduce:
0. On host,sync the time: #ntpdate clock.redhat.com
1. Boot multiple vms on a host. (1.5X mem and 3X cpu overcommiit)

 /usr/libexec/qemu-kvm -M rhel6.3.0 -cpu Opteron_G2 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -name AMD-win-1 -uuid 662ff010-d98a-4533-beb9-01fa35eecf10 -k en-us -rtc base=localtime,clock=host,driftfix=slew -no-kvm-pit-reinjection -usb -device usb-tablet,id=input0 -device virtio-serial-pci,id=virtio-serial0,max_ports=2,bus=pci.0,addr=0x3 -chardev file,id=charchannel0,path=/tmp/win-socket-1 -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -drive file=/home/qzhang-test/win2k8-r2-virtio-1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -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,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=net0,mac=0a:23:ae:7a:12:10,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -chardev socket,id=111a,path=/tmp/monitor-win-1,server,nowait -mon chardev=111a,mode=readline -vnc :1

2. sync the time of guest and run a script to check the time every few seconds.
:loop
ntpdate -b -q clock.redhat.com >> a.log
echo  >> a.log
timeout 5
goto :loop

3.
  
Actual results:
Windows guest got -21 second time drift on the AMD host and -37 seconds on the Intel host.

Expected results:


Additional info:
Intel host:
processor	: 15
vendor_id	: GenuineIntel
cpu family	: 6
model		: 44
model name	: Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
stepping	: 2
cpu MHz		: 2393.997
cache size	: 12288 KB
physical id	: 0
siblings	: 8
core id		: 10
cpu cores	: 4
apicid		: 21
initial apicid	: 21
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt aes lahf_lm ida arat dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4787.83
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:


AMD host:
processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 2
model name	: AMD Phenom(tm) 9600B Quad-Core Processor
stepping	: 3
cpu MHz		: 1150.000
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs npt lbrv svm_lock
bogomips	: 4587.47
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

====================================================
on AMD:
[root@localhost qzhang-test]# kvm_stat -1
efer_reload                    0         0
exits                 2515025410      6487
fpu_reload            1429925928      4078
halt_exits             136254067       354
halt_wakeup            127768074       304
host_state_reload     1430526594      4030
hypercalls                     0         0
insn_emulation         544772612      1097
insn_emulation_fail            0         0
invlpg                         0         0
io_exits              1279432982      3690
irq_exits              158087960       432
irq_injections         340527904       703
irq_window                     0         0
largepages                 27941         0
mmio_exits               4247255         0
mmu_cache_miss            379081         2
mmu_flooded                    0         0
mmu_pde_zapped                 0         0
mmu_pte_updated                0         0
mmu_pte_write              15120         0
mmu_recycled              313959        21
mmu_shadow_zapped         362662        21
mmu_unsync                     0         0
nmi_injections                 0         0
nmi_window                     0         0
pf_fixed                79498718       192
pf_guest                       0         0
remote_tlb_flush        14501523       148
request_irq                    0         0
signal_exits                  12         0
tlb_flush                      0         0

=========================================
script running inside guest:
:loop
ntpdate -b -q clock.redhat.com >> a.log
echo  >> a.log
timeout 5
goto :loop
Comment 1 Qunfang Zhang 2012-05-21 00:41:22 EDT
Created attachment 585713 [details]
time drift log of windows guest

Checked the log, actually the time will be adjust to normal when the drift value is about 60s. And then the new round of drift starts.

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