Bug 1115340
Summary: | [RFE] Clock in KVM guest is not up-to-date after save-to-disk/restore | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Sachin Raje <sraje> |
Component: | qemu-kvm | Assignee: | Marcelo Tosatti <mtosatti> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | Dayle Parker <dayleparker> |
Priority: | medium | ||
Version: | 6.6 | CC: | chayang, jen, jherrman, jraju, juzhang, knoel, mdshaikh, mkalinin, mkenneth, mprivozn, mtosatti, qiguo, qzhang, rbalakri, rpacheco, salmy, sraje, virt-maint |
Target Milestone: | rc | Keywords: | FutureFeature, TestOnly |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Release Note | |
Doc Text: |
kvm-clock correctly synchronizes VM system time after suspend
KVM virtual machines use the kvm-clock utility as the time source that synchronizes the virtual machine system time with the host system time after resuming from suspend mode. Previously, in some cases when a virtual machine running on a Red Hat Enterprise Linux 6 host was suspended to disk and then restored, the virtual machine's system time did not correctly synchronize with the host system time. With this update, kvm-clock has been modified to reliably synchronize with the system time on the host.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2015-07-22 06:05:51 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1190248, 1190256, 1191182 | ||
Bug Blocks: | 1156194 |
Comment 8
Julio Cesar Faracco
2014-11-03 19:18:38 UTC
(In reply to Julio Cesar Faracco from comment #8) > Hi everyone. > > I noticed the same problem here. > Specially when clock is defined as UTC (-rtc base=utc). > When qemu runs with the clock settings as "localtime", it does not occur. > > Maybe, this issue is related to mc146818rtc hardware. The clock value must > be redefined when the machine is restored. But, What are the consequences of > a real time application when you redefine the clock settings? > > Steps to reproduce: > > root# virsh > virsh # managedsave Ubuntu > [after a while...] > virsh # start Ubuntu Julio, To sync the guests clock, the following command should be issued: virsh qemu-agent-command $dom '{"execute":"guest-set-time"}' virsh qemu-monitor-command $dom '{"execute":"rtc-reset-reinjection"}' Provided the guests support guest-set-time properly. Verify this bug with qemu-kvm-0.12.1.2-2.458.el6.x86_64 and with qemu-guest-agent-0.12.1.2-2.458.el6.x86_64 installed in both host and guest. Steps: 1.Boot guest with virtagent # /usr/libexec/qemu-kvm -cpu Opteron_G1 -enable-kvm -m 100G -smp 12,sockets=1,cores=12,threads=1 -name rhel6 -drive file=/mnt/rhel6.7cp2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 -boot menu=on -monitor stdio -netdev tap,id=hostnet0,script=/etc/qemu-ifup,vhost=on -device virtio-net-pci,netdev=hostnet0,mac=54:52:00:1a:2c:01,id=test -nodefaults -nodefconfig -spice port=5910,seamless-migration=on,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -qmp unix:/tmp/q1,server,nowait -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0 -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 2.check guest time, and make sure qemu-ga is running # date Mon Mar 16 05:25:42 EDT 2015 # service qemu-ga status qemu-ga (pid 2778) is running... 3.Stop guest: (qemu) stop 4.wait for 10+ minutes, then continue guest: (qemu) c Check guest time: # date Mon Mar 16 05:25:48 EDT 2015 5.Execute "guest-set-time" via virtagent # nc -U /tmp/qga.sock {"execute":"guest-ping"} {"return": {}} {"execute":"guest-set-time"} {"return": {}} 6.Check time inside guest again: # date Mon Mar 16 05:38:10 EDT 2015 the time is synced with host, so this bug is fixed. Hi, Marcelo Is above right for verify this bug, could you help have a look, then we can set it as verified. Thanks, Qian Retest this bug with windows2012r2 guest: # /usr/libexec/qemu-kvm -cpu SandyBridge -enable-kvm -m 4G -smp 4,sockets=1,cores=4,threads=1 -name rhel7base -rtc base=localtime,clock=host,driftfix=none -drive file=/home/win212r2.qcow2,if=none,id=drive-ide-disk0,format=qcow2,werror=stop,rerror=stop,cache=none,aio=native -device ide-drive,drive=drive-ide-disk0,id=ide0 -boot menu=on -monitor stdio -nodefaults -nodefconfig -spice port=5910,seamless-migration=on,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -netdev tap,id=hostnet0,fd=5,vhost=on 5<>/dev/tap5 -device virtio-net-pci,netdev=hostnet0,ctrl_guest_offloads=off,id=vnet0,mac=6e:24:07:a6:63:23 -qmp unix:/tmp/q1,server,nowait -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0 -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 Have virtio-win-1.7.3-1.el7 installed inside: virtio-serial build: 62.71.104.9400 qemu-ga build: 7.0.0.10 steps: 1.Start guest 2.stop guest, and record the time 3.after 10 minutes, resume guest. 4.Check time inside guest, the time is still 10minutes ago 5.# nc -U /tmp/qga.sock {"execute":"guest-ping"} {"return": {}} {"execute":"guest-set-time"} {"return": {}} Result: 1. The time is not synced inside guest, is still the time 10minutes ago. 2. Every time do "{"execute":"guest-set-time"}" , the qmp will output sth like this: {"timestamp": {"seconds": 1426847421, "microseconds": 107634}, "event": "RTC_CHANGE", "data": {"offset": -814}} Additional info: 1. whether do '{"execute":"rtc-reset-reinjection"}', no affect the test result. 2.even test with -rtc base=localtime,clock=host,driftfix=slew , same result. 3.and test with -rtc base=localtime,driftfix=none, same result. 4.According to bug 1071499 , it is not fixed already.
>
> 4.According to bug 1071499 , it is not fixed already.
not fixed already / not fixed yet.
Additional info: Retest windows7 64bit guest with -rtc base=localtime,clock=host,driftfix=slew steps as comment 14 After stop the guest for a while(I stop it for 10+ minutes), then continue guest, the time of the guest will try to catch up host time crazily, and then do qmp command {"execute":"rtc-reset-reinjection"} , the time device of guest will run normally, but did not sync the host time, then I try to use agent command: {"execute":"guest-set-time"} but this command is not working as linux guest, the guest time did not sync as the host time. (In reply to Qian Guo from comment #13) > Verify this bug with qemu-kvm-0.12.1.2-2.458.el6.x86_64 and with > qemu-guest-agent-0.12.1.2-2.458.el6.x86_64 installed in both host and guest. > > Steps: > > 1.Boot guest with virtagent > # /usr/libexec/qemu-kvm -cpu Opteron_G1 -enable-kvm -m 100G -smp > 12,sockets=1,cores=12,threads=1 -name rhel6 -drive > file=/mnt/rhel6.7cp2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2, > werror=stop,rerror=stop,aio=native -device > virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 -boot menu=on > -monitor stdio -netdev tap,id=hostnet0,script=/etc/qemu-ifup,vhost=on > -device virtio-net-pci,netdev=hostnet0,mac=54:52:00:1a:2c:01,id=test > -nodefaults -nodefconfig -spice > port=5910,seamless-migration=on,disable-ticketing -vga qxl -global > qxl-vga.vram_size=67108864 -global PIIX4_PM.disable_s3=0 -global > PIIX4_PM.disable_s4=0 -qmp unix:/tmp/q1,server,nowait -device > virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0 -chardev > socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device > virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 > > 2.check guest time, and make sure qemu-ga is running > > # date > Mon Mar 16 05:25:42 EDT 2015 > # service qemu-ga status > qemu-ga (pid 2778) is running... > > > > 3.Stop guest: > (qemu) stop > > 4.wait for 10+ minutes, then continue guest: > (qemu) c > > Check guest time: > > # date > Mon Mar 16 05:25:48 EDT 2015 > > 5.Execute "guest-set-time" via virtagent > # nc -U /tmp/qga.sock > {"execute":"guest-ping"} > {"return": {}} > {"execute":"guest-set-time"} > {"return": {}} > > > 6.Check time inside guest again: > # date > Mon Mar 16 05:38:10 EDT 2015 > > > the time is synced with host, so this bug is fixed. > > Hi, Marcelo > > Is above right for verify this bug, could you help have a look, then we can > set it as verified. > > Thanks, > Qian Yes this is correct. Hi, Marcelo Do you mean that no need test the windows guest(it need windows qemu-ga driver) for this bug, since just Linux guest can pass this bug ? Just want to double confirm with you. Thanks, Qian (In reply to Qian Guo from comment #18) > Hi, Marcelo > > Do you mean that no need test the windows guest(it need windows qemu-ga > driver) for this bug, since just Linux guest can pass this bug ? > > Just want to double confirm with you. > > Thanks, > Qian (In reply to Qian Guo from comment #18) > Hi, Marcelo > > Do you mean that no need test the windows guest(it need windows qemu-ga > driver) for this bug, since just Linux guest can pass this bug ? > > Just want to double confirm with you. > > Thanks, > Qian Qian, Correct. (In reply to Marcelo Tosatti from comment #19) > (In reply to Qian Guo from comment #18) > > Hi, Marcelo > > > > Do you mean that no need test the windows guest(it need windows qemu-ga > > driver) for this bug, since just Linux guest can pass this bug ? > > > > Just want to double confirm with you. > > > > Thanks, > > Qian > (In reply to Qian Guo from comment #18) > > Hi, Marcelo > > > > Do you mean that no need test the windows guest(it need windows qemu-ga > > driver) for this bug, since just Linux guest can pass this bug ? > > > > Just want to double confirm with you. > > > > Thanks, > > Qian > > Qian, > > Correct. Thanks, and according to this comment, I will set this bug as verified 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. https://rhn.redhat.com/errata/RHBA-2015-1275.html |