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 978120 - Adjusting host time then reboot the RHEL6.4 guest but the guest system time can not adjust accordingly
Summary: Adjusting host time then reboot the RHEL6.4 guest but the guest system time c...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Marcelo Tosatti
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-26 02:46 UTC by ShupingCui
Modified: 2013-07-11 22:46 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-05 19:36:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
dmesg (32.34 KB, application/x-gzip)
2013-07-04 03:35 UTC, ShupingCui
no flags Details

Description ShupingCui 2013-06-26 02:46:57 UTC
Description of problem:
rhel6 guest system time does not correct after reboot when host clock is set forward

Version-Release number of selected component (if applicable):
host:
kernel-3.10.0-0.rc4.59.el7.x86_64
qemu-kvm-1.5.0-2.el7.x86_64
guest:
kernel-2.6.32-358.14.1.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. in host, ntpdate clock.redhat.com and check time
# date
Wed Jun 26 10:20:03 CST 2013
2. boot the guest
/usr/libexec/qemu-kvm \
    -name 'vm1' \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20130621-100435-VZyl373p,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control \
    -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130621-100435-VZyl373p,server,nowait \
    -device isa-serial,chardev=serial_id_serial1 \
    -chardev socket,id=seabioslog_id_20130621-100435-VZyl373p,path=/tmp/seabios-20130621-100435-VZyl373p,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20130621-100435-VZyl373p,iobase=0x402 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=0x4 \
    -drive file='/root/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/RHEL-Server-6.4-64-virtio.qcow2',if=none,id=drive-virtio-disk1,media=disk,cache=none,snapshot=off,format=qcow2,aio=native \
    -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1 \
    -net none \
    -m 4096 \
    -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
    -cpu 'Nehalem' \
    -M pc \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
    -vnc :0 \
    -vga cirrus \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off   \
    -no-kvm-pit-reinjection \
    -enable-kvm \
    -monitor stdio
3. in guest check time
# date
Wed Jun 26 10:20:44 CST 2013
# hwclock
Wed 26 Jun 2013 10:20:49 AM CST  -0.227913 seconds
4. in host, set system time forward
# date -s 12:00:00
Wed Jun 26 12:00:00 CST 2013
5. reboot the guest and check time

Actual results:
# date
Wed Jun 26 10:23:03 CST 2013
# hwclock
Wed 26 Jun 2013 10:23:01 AM CST  -0.257295 seconds

Expected results:
guest system time like this:
Wed Jun 26 12:00:54 CST 2013

Additional info:
in guest:
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock

Comment 2 ShupingCui 2013-06-26 03:09:13 UTC
host cpuinfo:
processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 26
model name	: Intel(R) Xeon(R) CPU           E5504  @ 2.00GHz
stepping	: 5
microcode	: 0xf
cpu MHz		: 1596.000
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 6
initial apicid	: 6
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 3989.97
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

Comment 3 ShupingCui 2013-06-26 03:36:19 UTC
Additional infos:
1. Tried rhel7.0 guest, guest system time can adjust accordingly
2. Tried win7 guest, guest system time can adjust accordingly as well
3. Adjust host forward and backward, RHEL6.4 guest can not adjust accordingly.

Comment 4 Marcelo Tosatti 2013-06-30 16:39:50 UTC
ShupingCui,

The guest uses the host monotonic clock, even for wallclock. The host monotonic
clock is not affected by changes in host system time.

Therefore it is expected that RHEL6 and RHEL7 guests should not synchronize to the hosts system time. Can you confirm the RHEL7 guest does not has its system time adjusted after reboot ? (given that no network connection is provided, to keep ntp from synchronizing the guest clock).

Comment 5 Marcelo Tosatti 2013-06-30 16:48:43 UTC
*** Bug 978946 has been marked as a duplicate of this bug. ***

Comment 6 ShupingCui 2013-07-01 03:14:06 UTC
(In reply to Marcelo Tosatti from comment #4)
> ShupingCui,
> 
> The guest uses the host monotonic clock, even for wallclock. The host
> monotonic
> clock is not affected by changes in host system time.
> 
> Therefore it is expected that RHEL6 and RHEL7 guests should not synchronize
> to the hosts system time. Can you confirm the RHEL7 guest does not has its
> system time adjusted after reboot ? (given that no network connection is
> provided, to keep ntp from synchronizing the guest clock).

Hi marcelo,

1. in host, ntpdate clock.redhat.com and check time
# ntpdate clock.redhat.com
 1 Jul 11:00:50 ntpdate[1423]: adjust time server 10.5.26.10 offset -0.000256 sec
2. boot the rhel7.0 guest(kernel-3.10.0-0.rc6.63.el7.x86_64)
/usr/libexec/qemu-kvm \
    -name 'vm1' \
    -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130621-100435-VZyl373p,server,nowait \
    -device isa-serial,chardev=serial_id_serial1 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=0x4 \
    -drive file='/root/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/RHEL-Server-7.0-64-virtio.qcow2',if=none,id=drive-virtio-disk1,media=disk,cache=none,snapshot=off,format=qcow2,aio=native \
    -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1 \
    -net none \
    -m 4096 \
    -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
    -cpu 'Nehalem' \
    -M pc \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
    -vnc :0 \
    -vga cirrus \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off   \
    -no-kvm-pit-reinjection \
    -enable-kvm \
    -monitor stdio
3. check guest time
# date
Mon Jul  1 11:01:41 CST 2013
# hwclock
Mon 01 Jul 2013 11:01:45 AM CST  -0.062650 seconds
4. in host, set system time forward
# date -s 12:00:00
Mon Jul  1 12:00:00 CST 2013
5. reboot the guest then check guest time
# date
Mon Jul  1 12:00:42 CST 2013
# hwclock
Mon 01 Jul 2013 12:00:45 PM CST  -0.323490 seconds

Comment 7 ShupingCui 2013-07-01 03:52:23 UTC
(In reply to Marcelo Tosatti from comment #4)
> ShupingCui,
> 
> The guest uses the host monotonic clock, even for wallclock. The host
> monotonic
> clock is not affected by changes in host system time.
Hi Marcelo,

With QE understanding, The guest can not synchronize the host time except the following actions, Guest kernel will re-read the host system time. QE's test result can prove this. I tested the following scenarios with guest's network disabled.
1. Boot/Reboot. 
1). Sync the host time
2). Adjust host time forward or backward by using "date -s"
3). boot/reboot guest
--Results--
Win7 guest    The guest can sync the host time
Rhel7 guest   The guest can sync the host time
RHEL6 guest   The Can not sync the host time, that's why I file this bug.

2. Stop/Continue.
1). Sync the host time and boot the guest
2). stop guest 10 mins
3). continue guest
--Results--
Win7 guest    The guest can sync the host time
Rhel7 guest   The guest can sync the host time
RHEL6 guest   The guest can sync the host time

3. S3/S4.
1). Sync the host time and boot the guest
2). S3/S4 guest
--Results--
Win7 guest    The guest can sync the host time
RHEL6 guest   The guest can sync the host time

> 
> Therefore it is expected that RHEL6 and RHEL7 guests should not synchronize
> to the hosts system time. Can you confirm the RHEL7 guest does not has its
> system time adjusted after reboot ? (given that no network connection is
> provided, to keep ntp from synchronizing the guest clock).

Comment 8 Marcelo Tosatti 2013-07-01 17:49:22 UTC
ShupingCui,

Please boot log of guests:

1) RHEL7 guest, boot with host system clock A, then boot with host system clock B.

2) RHEL6 guest, boot with host system clock A, then boot with host system clock B.

Comment 9 ShupingCui 2013-07-02 11:25:10 UTC
(In reply to Marcelo Tosatti from comment #8)
> ShupingCui,
> 
> Please boot log of guests:
> 
> 1) RHEL7 guest, boot with host system clock A, then boot with host system
> clock B.
> 
> 2) RHEL6 guest, boot with host system clock A, then boot with host system
> clock B.

Hi Marcelo,
i tested the following scenarios,
1. boot with host system clock A
1). set the host system clock A
2). boot the guest

2. boot with host system clock B
1). set the host system clock B
2). boot the guest

the results:
+------+---------------------------------+---------------------------------+
|      | host system clock A             | host system clock B             |
|      | # date -s 15:00:00              | # date -s 16:00:00              |
+------+---------------------------------+---------------------------------+
|RHEL7 | # date                          | # date                          |
|guest | Tue Jul  2 15:00:49 CST 2013    | Tue Jul  2 16:00:43 CST 2013    |
|      | # hwclock                       | # hwclock                       |
|      | Tue 02 Jul 2013 03:00:50 PM CST | Tue 02 Jul 2013 04:00:45 PM CST |
+------+---------------------------------+---------------------------------+
|RHEL6 | # date                          | # date                          |
|guest | Tue Jul  2 15:00:49 CST 2013    | Tue Jul  2 16:00:48 CST 2013    |
|      | # hwclock                       | # hwclock                       |
|      | Tue 02 Jul 2013 03:00:49 PM CST | Tue 02 Jul 2013 04:00:49 PM CST |
+------+---------------------------------+---------------------------------+

i also tried the reboot guest:
1). set the host system clock A
2). boot guest with "-rtc base=utc,clock=host"
3). set the host system clock B
4). reboot the guest
--Results--
Win7 guest    The guest system time can sync the host timeB
RHEL7 guest   The guest system time and hwclock can sync the host timeB
RHEL6 guest   The guest system time and hwclock cannot sync the host timeB

Comment 10 Marcelo Tosatti 2013-07-02 22:38:03 UTC
ShupingCui,

Sorry, i asked to attach boot log of guests (my message was not clear). That
is attach dmesg in each of the 4 cases in table of comment 9.

Comment 11 ShupingCui 2013-07-04 03:35:05 UTC
Created attachment 768582 [details]
dmesg

demsg_reboot file: boot with host system clock A, set host system clock to B, then reboot guest

Comment 12 Marcelo Tosatti 2013-07-04 23:07:26 UTC
ShupingCui,

If you change the following line of the file /etc/init.d/halt, in the RHEL6 guest:

From:
[ -x /sbin/hwclock -a -e /dev/rtc ] && action $"Syncing hardware clock to system time" /sbin/hwclock --systohc

To:
#[ -x /sbin/hwclock -a -e /dev/rtc ] && action $"Syncing hardware clock to system time" /sbin/hwclock --systohc

Does the guest still fail to sync from host system time after rebooting?

Comment 13 ShupingCui 2013-07-05 10:47:54 UTC
(In reply to Marcelo Tosatti from comment #12)
> ShupingCui,
> 
> If you change the following line of the file /etc/init.d/halt, in the RHEL6
> guest:
> 
> From:
> [ -x /sbin/hwclock -a -e /dev/rtc ] && action $"Syncing hardware clock to
> system time" /sbin/hwclock --systohc
> 
> To:
> #[ -x /sbin/hwclock -a -e /dev/rtc ] && action $"Syncing hardware clock to
> system time" /sbin/hwclock --systohc
> 
> Does the guest still fail to sync from host system time after rebooting?

hi marcelo,

after changing the /etc/init.d/halt, RHEL6 guest can sync from host system time after rebooting.

Comment 14 Marcelo Tosatti 2013-07-05 19:36:25 UTC
ShupingCui,

So this is not a bug: its behaviour of the guest. The guest chose to save
the time to the RTC, overwriting the RTC value which contains the host time.

Closing as NOTABUG, thanks.


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