Bug 1224023
| Summary: | The hwclock and systemclock of guest should be ccoincident while set a invalid domtime with guest agent | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | zhenfeng wang <zhwang> |
| Component: | qemu-guest-agent | Assignee: | Marc-Andre Lureau <marcandre.lureau> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | dyuan, hliu, huding, juzhang, knoel, lmiksik, mrezanin, mzhan, xfu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-guest-agent-2.3.0-4.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-19 07:11:28 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: | |||
You can't set hwtime >= 2070, this is a known system limit (1970 +100)
Linux drivers/char/rtc.c
/* These limits and adjustments are independent of
* whether the chip is in binary mode or not.
*/
if (yrs > 169) {
spin_unlock_irq(&rtc_lock);
return -EINVAL;
}
I think the agent should bail out earlier, so I sent a patch for that upstream:
https://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg01073.html
Fix included in qemu-guest-agent-2.3.0-4.el7 Reproduce this bug using the version:
qemu-kvm-rhev-2.3.0-23.el7.x86_64
kernel-3.10.0-314.el7.x86_64
qemu-kvm-rhev-2.3.0-1.el7.x86_64
Steps to Reproduce:
1.Configure a guest with guest agent
#virsh dumpxml rhel7.2
--
<channel type='unix'>
<source mode='bind' path='/var/lib/libvirt/qemu/channel/target/7.2.org.qemu.guest_agent.0'/>
<target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
<alias name='channel1'/>
<address type='virtio-serial' controller='0' bus='0' port='2'/>
</channel>
--
2.Start the guest
#virsh start rhel7.2
3.Check the domtime of the guest
# virsh domtime rhel7.2 --pretty
Time: 2015-09-18 04:46:16
4.Set the domtime with a big value, will report an error. However, check the domtime, found the guest's time changed actually.
# virsh domtime rhel7.2 3999999999
error: internal error: unable to execute QEMU agent command 'guest-set-time': hwclock failed to set hardware clock to system time
# virsh domtime 7.2 --pretty
Time: 2096-10-02 07:06:53
7.Check the hwclock and system time inside the guest, we could find that only the system time changed, the hardware time didn't change
guest# hwclock
Fri 18 Sep 2015 12:47:34 PM CST -0.444511 seconds
guest# date
Tue Oct 2 15:07:29 CST 2096
guest# date -u
Tue Oct 2 07:07:35 UTC 2096
Verify this bug using the version: qemu-kvm-rhev-2.3.0-23.el7.x86_64 kernel-3.10.0-314.el7.x86_64 qemu-kvm-rhev-2.3.0-4.el7.x86_64 The test steps are same as comment #5. 1.Configure a guest with guest agent #virsh dumpxml rhel7.2 -- <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/7.2.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel1'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> -- 2.Start the guest #virsh start rhel7.2 3.Check the domtime of the guest # virsh domtime rhel7.2 --pretty Time: 2015-09-18 05:04:30 4.Set the domtime with a big value, will report an error. However, check the domtime, found the guest's time did not changed. # virsh domtime rhel7.2 3999999999 error: internal error: unable to execute QEMU agent command 'guest-set-time': Invalid time # virsh domtime 7.2 --pretty Time: 2015-09-18 05:05:02 7.Check the hwclock and system time inside the guest, we could find that the system time and the hardware time didn't change guest# hwclock Fri 18 Sep 2015 01:05:16 PM CST -0.453719 seconds guest# date Fri Sep 18 13:05:13 CST 2015 Based on the above results, I think this bug has been fixed. 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-2217.html |
Description of problem: The hwclock and systemclock of guest should be ccoincident while set a invalid domtime with guest agent Version-Release number of selected component (if applicable): libvirt-1.2.15-2.el7.x86_64 kernel-3.10.0-254.el7.x86_64 qemu-kvm-rhev-2.3.0-1.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Configure a guest with guest agent #virsh dumpxml 7.2 -- <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/7.2.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel1'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> -- 2.Start the guest #virsh start 7.2 3.Check the domtime of the guest # virsh domtime 7.2 --pretty Time: 2015-04-27 02:46:11 4.Set the domtime with a big value, will report an error. However, check the domtime, found the guest's time changed actually. # virsh domtime 7.2 3999999999 error: internal error: unable to execute QEMU agent command 'guest-set-time': hwclock failed to set hardware clock to system time # virsh domtime 7.2 --pretty Time: 2096-10-02 07:06:42 7.Check the hwclock and system time inside the guest, we could find that only the system time changed, the hardware time didn't change guest# hwclock Mon 27 Apr 2015 10:49:29 AM CST -0.920839 seconds guest# date Tue Oct 2 15:09:44 CST 2096 guest# date -u Tue Oct 2 07:09:47 UTC 2096 Actual results: while set the domtime with a big value, will report an error , however, check the domtime, found the guest's time changed actually Expected results: The hwclock and systemclock of guest should be ccoincident while set a invalid domtime with guest agent Additional info: