Bug 602084 - QMP: RTC_CHANGE is not triggered when changing guest timezone by command
Summary: QMP: RTC_CHANGE is not triggered when changing guest timezone by command
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
(Show other bugs)
Version: 6.0
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: Luiz Capitulino
QA Contact: Virtualization Bugs
Depends On:
Blocks: 559201
TreeView+ depends on / blocked
Reported: 2010-06-09 05:56 UTC by juzhang
Modified: 2013-01-09 22:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-03 02:31:49 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Debug patch (2.34 KB, patch)
2010-07-03 02:34 UTC, Luiz Capitulino
no flags Details | Diff

Description juzhang 2010-06-09 05:56:01 UTC
Description of problem:
RTC_CHANGE is triggered when changing guest timezone by UI (Date/Time -> Time Zone).But it could not be triggered when changing guest timezone by command.

Version-Release number of selected component (if applicable):
#rpm -q qemu-kvm

How reproducible:

Steps to Reproduce:
1.boot guest with -qmp tcp:0:4444,server,nowait
/usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -startdate now -cpu qemu64,+sse2 -drive file=/opt/r5u5_64.raw -net nic,model=e1000,macaddr=20:20:10:27:17:01,vlan=0 -net tap,script=/etc/qemu-ifup,downscript=no,vlan=0 -m 2G -smp 2 -balloon none -boot c -monitor stdio -uuid `uuidgen` -vnc :1 -qmp tcp:0:4444,server,nowait
2.Connect to the qmp
3.Issue the qmp_capabilities command
#{ "execute": "qmp_capabilities" }
4.In guest
Change guest timezone by UI (Date/Time -> Time Zone).
5.In guest
Change guest timezone by following command:
date && hwclock  --show && /bin/cp  /usr/share/zoneinfo/America/Denver  /etc/localtime && sed -i 's/ZONE=\"Asia\/Shanghai\"/ZONE=\"America\/Denver\"/' /etc/sysconfig/clock && date && hwclock --show

Actual results:
After step 4, qmp emit the following event:
{"timestamp": {"seconds": 1275388442, "microseconds": 724709}, "event": "RTC_CHANGE", "data": {"offset": -14}}

After step 5, RTC_CHANGE is not triggered.qmp didn't emit any event.
Following is command output in guest os in step 5:
Wed Jun  2 10:51:42 CST 2010
Wed 02 Jun 2010 10:51:44 AM CST  -0.344424 seconds
Tue Jun  1 20:51:43 MDT 2010
Tue 01 Jun 2010 08:51:45 PM MDT  -0.969838 seconds

Expected results:
After step5,qmp monitor should emit notification event.

Additional info:

Comment 2 RHEL Product and Program Management 2010-06-09 06:13:41 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 3 Luiz Capitulino 2010-07-03 02:31:49 UTC
The rule is: the event is emitted whenever the RTC (hardware clock) time is changed by the guest.

This does happen in step 4. I'm not sure why, but Gnome is probably setting it. This can be easily confirmed by the 'info rtc_state' command, introduced by the attached debug patch:

(qemu) info rtc_state 

-> Change timezone by using Gnome's Date/Time app

(qemu) info rtc_state 

Of course that I was a bit lucky to get a huge difference, you might not realize the RTC was changed if the delta is just a few seconds.

Now, the most important. In step 5 the event is not emitted because the RTC time is _not_ changed. What you're doing is updating the timezone files. The time showed by hwclock --show changes because it shows the local time, not a direct read of the RTC, as explained by hwclock's manpage:

-r, --show
       Read  the  Hardware Clock and print the time on Standard Output.
       The time shown is always in local time, even if  you  keep  your
       Hardware  Clock  in  Coordinated  Universal Time.

The 'info rtc_state' command can also confirm this:

(qemu) info rtc_state 

-> Update the timezone files, like what's done by step 5

(qemu) info rtc_state 

The difference shown is the regular RTC update, it's not the huge difference showed above.

Conclusion: everything is working as expected, closing this as NOTABUG.

Comment 4 Luiz Capitulino 2010-07-03 02:34:07 UTC
Created attachment 429214 [details]
Debug patch

Note You need to log in before you can comment on or make changes to this bug.