Time synchronization in guest machine

Latest response

Hi,

I have a question, Linux customers have the wrong time, with a lag of a few seconds over time.

The hypervisors have when properly configured.

Not if I activate NTP service customers, or whether the customer takes the time hypervisor.

I tested. I have a client without NTP and has a gap of 10 seconds and rising.

I have another client with the NTP service started, but with a lag of a few seconds.

As I read, would be enough to put this in the ntp.conf configuration and comment lines of "server"

server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10

Linux clients are not synchronized with HOSTs? RHEV must be enabled in the NTP client pointing to a time server?

more info:
HOST: RHEV 3.1
Guest: RHEL 5.7 (machines migrated from xen)

Thanks!

Jose Antonio Vico Palomino's picture
Log in to join the conversation

Responses

cs Community Member 50 points
11 November 2013 9:00 AM

hi .. i never use before rhev , but for physical hardware , just configure /etc/ntp.conf ,
i also configure /etc/ntp.conf at vmware guest , vmware guest able to sync the time to server .

the below option to let your server as ntp server .
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10

for diagnostic ntp client , maybe you can provide command output below :

ntpq -p

ntpdate -d ntp_server_ip

hope this can help you

ja Guru 1340 points
11 November 2013 9:56 AM

We run NTP on VMs the same way that we do on physical machines. I.e. both hypervisors and VMs are configure to syncronize time against a set of external NTP servers. I don't think it's a good idea to syncronizing NTP against a local clock...

BTW: with XEN we used the kernel parameters "clocksource=pit nohpet nopmtimer" to get stable time, maybe you have these too, and need to remove them after migrating your guests to RHEV ?

Ref: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/KVM_virtual_machine_timing_management.html

Jose Antonio Vico Palomino's picture Pro 484 points
11 November 2013 10:31 AM

It is not synchronize the client against an external NTP server. I think there is the possibility that the client take time for your host.

Although the machines were migrated from Xen to RHEV, contain no kernel parameters. Only this:

[root@srkmsaecnt01 ~]# cat /boot/grub/grub.conf
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-274.3.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-274.3.1.el5 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-274.3.1.el5.img

Logically I know we can synchronize directly against a time server. But we want to take the time hypervisor. If it can be .. :-)

As this may be the solution, which try as soon as possible.

https://access.redhat.com/site/solutions/33267

David Powles's picture Red Hat Guru 25369 points
11 November 2013 12:11 PM

Thanks Jose. Let us know if that solution works for your issue.

AA Expert 1157 points
11 November 2013 10:35 PM

There was an earlier discussion about clocksources in RHEL 6 guests (kvm-clock):

https://access.redhat.com/discussion/63415

Looking at a RHEL 5 guest on a RHEL 6 (libvirt managed) host, I see the following configurations about clocksources. I am not noticing any time lag.

[root@wyvern ~]# dmesg | grep -i clock
kvm-clock: cpu 0, msr 7eff:804ab401, boot clock
kvm-clock: cpu 0, msr 0:2535401, primary cpu clock
kvm-clock: cpu 1, msr 0:253da81, secondary cpu clock
Real Time Clock Driver v1.12ac
[root@wyvern ~]#
[root@wyvern ~]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
jiffies
[root@wyvern ~]#
[root@wyvern ~]# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies

In a RHEL 6 guest running on the same host, the current_clocksource is kvm-clock:

[root@aragon ~]# dmesg | grep kvm-clock
kvm-clock: Using msrs 4b564d01 and 4b564d00
kvm-clock: cpu 0, msr 0:1c25681, boot clock
kvm-clock: cpu 0, msr 0:28216681, primary cpu clock
kvm-clock: cpu 1, msr 0:28296681, secondary cpu clock
kvm-clock: cpu 2, msr 0:28316681, secondary cpu clock
kvm-clock: cpu 3, msr 0:28396681, secondary cpu clock
Switching to clocksource kvm-clock

[root@aragon ~]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock

[root@aragon ~]# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock tsc acpi_pm

Jose Antonio Vico Palomino's picture Pro 484 points
12 November 2013 10:24 AM

I'm, still, by testing. When finished testing, I will report the results. The fact is that the tests take several days, as it is time lag does not occur immediately.

Reference But what says Aram. My result (RHEL5):

[root@srkmsapcnt01 ~]# dmesg | grep -i time
ACPI: PM-Timer IO Port: 0xb008
Calibrating delay loop (skipped), value calculated using timer frequency.. 4655.03 BogoMIPS (lpj=2327518)
Using local APIC timer interrupts.
WARNING calibrate_APIC_clock: the APIC timer calibration may be wrong.
Detected 62.501 MHz APIC timer.
time.c: Using 1.193182 MHz WALL KVM GTOD KVM timer.
time.c: Detected 2327.518 MHz processor.
Real Time Clock Driver v1.12ac
PCI: Setting latency timer of device 0000:00:01.1 to 64
PCI: Setting latency timer of device 0000:00:01.2 to 64
SELinux: Disabled at runtime.

[root@srkmsapcnt01 ~]# dmesg | grep -i clock
kvm-clock: cpu 0, msr 7eff:8049f401, boot clock
kvm-clock: cpu 0, msr 0:3335401, primary cpu clock
WARNING calibrate_APIC_clock: the APIC timer calibration may be wrong.
Real Time Clock Driver v1.12ac

[root@srkmsapcnt01 ~]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
jiffies
[root@srkmsapcnt01 ~]# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies