Hide Forgot
Created attachment 495737 [details] screenshot of result of ntpdate after savevm/loadvm Description of problem: After savevm, cursor in guest jumps quickly and run ntpdate -q clock.redhat.com returns offset 0.000000. I am not sure whether it is a bug or not, maybe it acts as expected. Version-Release number of selected component (if applicable): # rpm -qa|grep qemu-kvm qemu-kvm-debuginfo-0.12.1.2-2.159.el6.x86_64 qemu-kvm-0.12.1.2-2.159.el6.x86_64 qemu-kvm-tools-0.12.1.2-2.159.el6.x86_64 # uname -r 2.6.32-131.0.1.el6.x86_64 How reproducible: 70% Steps to Reproduce: 1. boot a windows guest by: /usr/libexec/qemu-kvm -M rhel6.1.0 -enable-kvm -m 2048 -smp 2 -name windows -uuid `uuidgen` -rtc base=localtime,clock=host,driftfix=slew -boot c -drive file=/root/win7-32-virtio.qcow2,if=none,id=drive-virtio-0-0,media=disk,format=qcow2,cache=none -device virtio-blk-pci,drive=drive-virtio-0-0,id=virt0-0-0 -netdev tap,id=hostnet1 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:40:e1:a1:13 -usb -device usb-tablet,id=input1 -vnc :0 -monitor stdio -balloon none 2. issue savevm in monitor 3. Actual results: After savevm, cursor in guest jumps quickly and running ntpdate -q clock.redhat.com returns: offset 0.000000, delay 0.00000. Same issue happens when issue loadvm. But wait for several seconds, it will act normal. Expected results: Additional info:
This sounds like normal suspend / resume behavior to me - cursor motions and acceleration are time sensitive and it's relatively normal for that to be slightly disrupted after a suspend / resume event, as long as everything returns back to normal in a few seconds.
Agree, external hibernation is a problem for timing.