RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1171700 - 'hwclock' in destination guest returns to base '2006-06-06' after migration
Summary: 'hwclock' in destination guest returns to base '2006-06-06' after migration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: ppc64
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: David Gibson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1170132
Blocks: RHEV3.6PPC
TreeView+ depends on / blocked
 
Reported: 2014-12-08 12:30 UTC by Gu Nini
Modified: 2016-02-21 10:56 UTC (History)
13 users (show)

Fixed In Version: qemu-kvm-rhev-2.2.0-8.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-04 16:22:57 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
hwclock returns to base time after migration-12082014.png (90.87 KB, image/png)
2014-12-08 12:30 UTC, Gu Nini 		no flags Details
hwclock returns to the base time after migration the 2nd turn-12082014.png (85.19 KB, image/png)
2014-12-08 12:38 UTC, Gu Nini 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 119632 0 None None None Never
Red Hat Product Errata RHBA-2015:2546 0 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2015-12-04 21:11:56 UTC

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
Note You need to log in before you can comment on or make changes to this bug.