Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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:
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 3Dr. David Alan Gilbert
2014-12-09 17:01:41 UTC
I notice the -help on upstream qemu says that -rtc driftfix is x86 only.
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
(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 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.
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: