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-rhevAssignee: David Gibson <dgibson>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.1CC: 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:
Description Flags
hwclock returns to base time after migration-12082014.png
none
hwclock returns to the base time after migration the 2nd turn-12082014.png none

Description Gu Nini 2014-12-08 12:30:23 UTC
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:

Comment 1 Gu Nini 2014-12-08 12:38:10 UTC
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.

Comment 3 Dr. David Alan Gilbert 2014-12-09 17:01:41 UTC
I notice the -help on upstream qemu says that -rtc driftfix is x86 only.

Comment 4 David Gibson 2014-12-09 23:21:00 UTC
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.

Comment 5 David Gibson 2014-12-10 04:19:59 UTC
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 6 IBM Bug Proxy 2014-12-10 13:41:13 UTC
------- 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

Comment 7 David Gibson 2014-12-11 05:11:30 UTC
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

Comment 8 Gu Nini 2014-12-11 09:50:03 UTC
(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.

Comment 9 David Gibson 2014-12-12 01:28:28 UTC
Thanks for the feedback.

I'm working towards getting this fix upstream.

Comment 10 IBM Bug Proxy 2015-01-12 21:22:10 UTC
------- 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.

Comment 11 David Gibson 2015-01-13 00:04:03 UTC
No, I'm afraid it is not upstream yet.  I need to resend my patch series.

Comment 12 David Gibson 2015-01-29 05:02:40 UTC
Draft patches posted upstream, see https://www.mail-archive.com/qemu-devel@nongnu.org/msg271868.html

Still under discussion.

Comment 14 Miroslav Rezanina 2015-03-19 09:08:15 UTC
Fix included in qemu-kvm-rhev-2.2.0-8.el7

Comment 16 Gu Nini 2015-08-21 11:17:43 UTC
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

Comment 18 errata-xmlrpc 2015-12-04 16:22:57 UTC
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