Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle

[Matthew Anderson]

Thanks for the suggestion but so far it hasn't made any difference.

I thought I may be an issue with the mainline kernel I was using so I changed 
over to Ubuntu 12.10 and QEMU 1.2.0. Stability is slightly better but I still 
get 2-3 VM's a day out of about 120 experiencing this bug in the exact same way 
as before.  Time in the guest simply stop's ticking over and when you attempt 
to interact with the VM the lost ticks get replayed as fast as possible. 
Because of the time being out practically nothing works as it breaks crypto 
support (as well as practically everything else).

In addition to what I posted previously I've tried -
Setting the CPU type to host, qemu64 and kvm64
Setting the machine type to 0.14, 0.15, 1.0, 1.1 and 1.2 (plus 1.3 and 1.4 from 
previous testing)
With and without the HPET timer using combinations of the above

The settings I'm using work fine on the Centos 6.3 (2.6.32) kernel and QEMU 
1.4.0. I've only had this problem since upgrading the kernel which is the only 
evidence I have of it being a kernel/KVM bug. I'm incredibly desparate for any 
solution or advice that may lead to getting this problem sorted,I'm getting a 
tyrade of angry phone called every morning that's making me want to go postal. 

Thanks
-Matt

-----Original Message-----
From: fluxion [mailto:address@hidden On Behalf Of mdroth
Sent: Friday, 22 February 2013 6:23 AM
To: Matthew Anderson
Cc: 'address@hidden'
Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle

On Thu, Feb 21, 2013 at 06:16:10PM +0000, Matthew Anderson wrote:
> If this isn't the correct list just let me know,
> 
> I've run into a bug whereby a Windows guest (tested on Server 2008R2 and 
> 2012) no longer receives RTC ticks when it has been idle for a random amount 
> of time. HPET is disabled and the guest is running Hyper-V relaxed timers 
> (same situation without hv_relaxed). The guest clock stands still and the 
> qemu process uses very little CPU (<0.5%, normally it's >5% when the guest is 
> idle) . Eventually the guest stops responding to network requests but if you 
> open the guest console via VNC and move the mouse around it comes back to 
> life and QEMU replays the lost RTC ticks and the guest recovers. I've also 
> been able to make it recover by querying the clock over the network via the 
> net time command, you can see the clock stand still for 30 seconds then it 
> replays the ticks and catches up.
> 
> I've tried to reproduce the issue but it seems fairly illusive, the only way 
> I've been able to reproduce it is by letting the VM's idle and waiting. 
> Sometimes it's hours and sometimes minutes. Can anyone suggest a way to 
> narrow the issue down?
> 
> Qemu command line is-
> /usr/bin/kvm -name SQL01 -S -M pc-0.14 -cpu qemu64,hv_relaxed 
> -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -uuid 
> 5f54333b-c250-aa72-c979-39d156814b85 -no-user-config -nodefaults 
> -chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/iHost-SQL01.monitor,s
> erver,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc 
> base=localtime -no-hpet -no-shutdown -device 
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
> file=/mnt/gluster1-norep/iHost/SQL01.qed,if=none,id=drive-virtio-disk0
> ,format=qed,cache=writeback -device 
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id
> =virtio-disk0 -drive 
> file=/mnt/gluster1-norep/iHost/SQL01-Data.qed,if=none,id=drive-virtio-
> disk2,format=qed,cache=writeback -device 
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk2,id
> =virtio-disk2 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw 
> -device 
> ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 
> -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=39 -device 
> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2c:8d:23,bus=pci.0
> ,addr=0x3 -chardev pty,id=charserial0 -device 
> isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 
> -vnc 127.0.0.1:22 -vga cirrus -device 
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
> 
> Environment is -
> Mainline 3.7.5 and 3.8.0
> Qemu 1.2.2, 1.3.1 and 1.4.0

Were all of these with -M pc-0.14? Only thing that stands out to me is 
kernel_irqchip being disabled in your case. -M 1.1 and higher will enable it by 
default. Worth a shot.

> Scientific Linux 6.3
> KSM enabled, transparent hugepages disabled.
> Dual Xeon 5650
> 192GB
> 
> Thanks all
>