Hide Forgot
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
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:
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.
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).
*** Bug 978946 has been marked as a duplicate of this bug. ***
(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
(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).
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.
(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
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.
Created attachment 768582 [details] dmesg demsg_reboot file: boot with host system clock A, set host system clock to B, then reboot guest
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?
(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.
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.