Bug 1171700
Summary: | 'hwclock' in destination guest returns to base '2006-06-06' after migration | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Gu Nini <ngu> | ||||||
Component: | qemu-kvm-rhev | Assignee: | David Gibson <dgibson> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 7.1 | CC: | amit.shah, dgilbert, fnovak, hannsj_uhl, hhuang, knoel, lmiksik, michen, quintela, sherold, virt-maint, xuhan, ypu | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | ppc64 | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | qemu-kvm-rhev-2.2.0-8.el7 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2015-12-04 16:22:57 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: | 1170132 | ||||||||
Bug Blocks: | 1201513 | ||||||||
Attachments: |
|
Created attachment 965835 [details]
hwclock returns to the base time after migration the 2nd turn-12082014.png
This is the terminal screenshot that hwclock is a little later than system time after 1st turn migration, and it returns to the base time after the 2nd turn migration.
I notice the -help on upstream qemu says that -rtc driftfix is x86 only. That's true. driftfix is x86 specific and should be removed from the Power tests. However, I think it's unlikely to be related to this specific bug. It's not the same bug, but the code where this bug lies will be changed significantly by the fix to bug 1170132 once ready. Therefore setting it as a blocking bug. I'll revisit this once my patches for 1170132 get into better shape. ------- Comment From fnovak.com 2014-12-10 13:33 EDT------- reverse mirror of RHBZBug 1171700 - 'hwclock' in destination guest returns to base '2006-06-06' after migration I think, though I'm not certain, that the rework necessary to fix bug 1170132 will also fix this one. Can you please retry with the draft fix found at: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=8363604 (In reply to David Gibson from comment #7) > I think, though I'm not certain, that the rework necessary to fix bug > 1170132 will also fix this one. Can you please retry with the draft fix > found at: > > http://brewweb.devel.redhat.com/brew/taskinfo?taskID=8363604 Yes. After upgrade the patches to do bug 1170132 verification, also found no the bug problem any more. Thanks. Thanks for the feedback. I'm working towards getting this fix upstream. ------- Comment From seg.com 2015-01-12 21:11 EDT------- David, is this upstream, yet? If it's not upstream and stable, we should defer this to 2.1.1.2. No, I'm afraid it is not upstream yet. I need to resend my patch series. Draft patches posted upstream, see https://www.mail-archive.com/qemu-devel@nongnu.org/msg271868.html Still under discussion. Fix included in qemu-kvm-rhev-2.2.0-8.el7 Verify the bug on both rhel7.2 BE/LE guests of rhel7.2 BE/LE hosts, the detailed sw versions are as follows: BE HOST Host kernel: 3.10.0-306.el7.ppc64 Guest kernel: 3.10.0-302.el7.ppc64/3.10.0-306.el7.ppc64le Qemu-kvm-rhev: qemu-kvm-rhev-2.3.0-18.el7.ppc64 LE HOST Host kernel: 3.10.0-306.el7.ppc64le Guest kernel: 3.10.0-302.el7.ppc64/3.10.0-306.el7.ppc64le Qemu-kvm-rhev: qemu-kvm-rhev-2.3.0-18.el7.ppc64le 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-2546.html |
Created attachment 965834 [details] hwclock returns to base time after migration-12082014.png Description of problem: If start guest with '-rtc base=2006-06-06,clock=host,driftfix=slew' or '-rtc base=2006-06-06,clock=vm,driftfix=slew', after migrating the guest to destination succesfully, the 'hwclock' in the destination guest returns to the base time '2006-06-06' Version-Release number of selected component (if applicable): Host kernel:3.10.0-201.el7.ppc64 Guest kernel:3.10.0-195.el7.ppc64/3.10.0-196.ael7a.ppc64le Qemu-kvm version: qemu-img-rhev-2.1.2-14.el7.ppc64 qemu-kvm-tools-rhev-2.1.2-14.el7.ppc64 qemu-kvm-common-rhev-2.1.2-14.el7.ppc64 qemu-kvm-rhev-2.1.2-14.el7.ppc64 qemu-kvm-rhev-debuginfo-2.1.2-14.el7.ppc64 How reproducible: 100% Steps to Reproduce: 1.Create guest A with following cmd: /usr/libexec/qemu-kvm -machine accel=kvm -name rhel7.1-1 -m 16384 -realtime mlock=off -smp 32,sockets=1,cores=4,threads=8 -uuid 95346a10-1828-403a-a610-ac5a52a29428 -no-user-config -nodefaults -monitor stdio -rtc base=2006-06-06,clock=host,driftfix=slew -no-shutdown -boot strict=on -device usb-ehci,id=usb,bus=pci.0,addr=0x2 -device pci-ohci,id=usb1,bus=pci.0,addr=0x1 -device spapr-vscsi,id=scsi0,reg=0x1000 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/home/ngu/rhel7.1-1.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,id=hostnet0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device spapr-vlan,netdev=hostnet0,id=net0,mac=52:54:00:c4:e7:24,reg=0x2000 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -vnc 0:14 -device VGA,id=video0,bus=pci.0,addr=0x4 -msg timestamp=on 2.Create the destination guest B on the same host with following cmd: /usr/libexec/qemu-kvm -machine accel=kvm -name rhel7.1-1 -m 16384 -realtime mlock=off -smp 32,sockets=1,cores=4,threads=8 -uuid 95346a10-1828-403a-a610-ac5a52a29428 -no-user-config -nodefaults -monitor stdio -rtc base=2006-06-06,clock=host,driftfix=slew -no-shutdown -boot strict=on -device usb-ehci,id=usb,bus=pci.0,addr=0x2 -device pci-ohci,id=usb1,bus=pci.0,addr=0x1 -device spapr-vscsi,id=scsi0,reg=0x1000 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/home/ngu/rhel7.1-1.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,id=hostnet0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device spapr-vlan,netdev=hostnet0,id=net0,mac=52:54:00:c4:e7:24,reg=0x2000 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -vnc 0:15 -device VGA,id=video0,bus=pci.0,addr=0x4 -msg timestamp=on -incoming tcp:0:5200 3.Make sure guest A is booted up; on guest A, check its system time and hardware time with cmd 'date' and 'hwclock' 4.Migrate guest A to guest B with (qemu) cmd "migrate tcp:0:5200" 5.After the migration finishes, in guest B, check its system time and hardware time with cmd 'date' and 'hwclock' 6.Compare the system time and hardware time obtained in step3 and step5 7.Create a new guest C as that in step1 only adding "-incoming tcp:0:5201" 8.Migrate guest B to guest C with (qemu) cmd "migrate tcp:0:5201" 9.After the migration finishes, in guest C, check its system time and hardware time with cmd 'date' and 'hwclock' 10.Compare the system time and hardware time obtained in step5 and step9 Actual results: In step5, the 'hwclock' returns to the base time '2006-06-06', while the system time continues; OR the 'hwclock' is a little late than the system time; In step10, the 'hwclock' returns to the base time '2006-06-06', while the system time continues Expected results: System time and hardware time should both continues after migration Additional info: