Synchronized time with kvm_clock

Synchronized time with kvm_clock

[Alex Hermann]

Hello all,

from the various sources google comes up with, it seems kvm_clock is now the 
preferred clock source for kvm guests. I was hoping it would keep the time 
synced with the host, but apparentely it doesn't. I'm seeing a pretty steady 1 
sec diff between host and guest. The host is synced with external time sources 
by means of ntp.

Am I supposed to run ntp inside the guest when using kvm_clock as a 
clocksource? Othwerwise, what clocksource should be used in the guest
1) to automatically get synced time with the host? or
2) which can be used alongside ntpd in the guest?


host:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

guest:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock


Pleas cc me, I'm not on the list.
-- 
Greetings,

Alex Hermann

Re: Synchronized time with kvm_clock

[Alex Hermann]

On Monday 26 April 2010, I wrote:
> host:
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
> 
> guest:
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> kvm-clock

Forgotten some info which might be essential:

Kernel (host and guest): 2.6.32-trunk-amd64
qemu-kvm: 0.12.3+dfsg-4


Please keep me on the cc, I'm not on the list.
-- 
Greetings,

Alex Hermann

Re: Synchronized time with kvm_clock

[John Buswell]

Alex,

You don't need to run ntp on each guest. You can enable rtc support in 
the guest kernel and on the hypervisor. Run ntp client on the hypervisor 
via cron, and use hwclock -w on the hypervisor after you run ntp, to 
sync the hardware clock to the system clock (which is now updated by 
ntpdate). On the guests, periodically run hwclock -s to set the system 
clock from the hw clock.

This seems to work extremely well, the clocksource on the guests as 
kvm_clock, and as long as you have the clocksource as hpet or acpi_pm on 
the hypervisor, there doesn't seem to be any problems with keeping time.

The only thing I've noticed is that when you reboot, the very first 
guest will have the wrong time on boot, so the uptime is messed up.

Regards

Alex Hermann wrote:
> On Monday 26 April 2010, I wrote:
>   
>> host:
>> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> tsc
>>
>> guest:
>> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> kvm-clock
>>     
>
> Forgotten some info which might be essential:
>
> Kernel (host and guest): 2.6.32-trunk-amd64
> qemu-kvm: 0.12.3+dfsg-4
>
>
> Please keep me on the cc, I'm not on the list.
>   


-- 
John Buswell
CEO, Carbon Mountain LLC
http://www.carbonmountain.com

Re: Synchronized time with kvm_clock

[Athanasius]

[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]

On Mon, Apr 26, 2010 at 10:32:51AM -0400, John Buswell wrote:
> You don't need to run ntp on each guest. You can enable rtc support in  
> the guest kernel and on the hypervisor. Run ntp client on the hypervisor  
> via cron, and use hwclock -w on the hypervisor after you run ntp, to  
> sync the hardware clock to the system clock (which is now updated by  
> ntpdate). On the guests, periodically run hwclock -s to set the system  
> clock from the hw clock.

  What a *horribly* hacky way to do it, meaning you'll get time warps
all over the place, admittedly of short intervals if you run those cron
jobs often enough.  It seems much simpler to me to simply run ntpd in
all the guests.  It's not like the extra CPU or bandwidth is going to be
a problem.  At the very least you want to run ntpd, not ntpdate out of
cron, in the hypervisor, and only use cron for those hwclock -w's.

> This seems to work extremely well, the clocksource on the guests as  
> kvm_clock, and as long as you have the clocksource as hpet or acpi_pm on  
> the hypervisor, there doesn't seem to be any problems with keeping time.
>
> The only thing I've noticed is that when you reboot, the very first  
> guest will have the wrong time on boot, so the uptime is messed up.

  And I think many people would find this unacceptable.

  Really, I appreciate that "keep the time sync'd via ntpd on the
hypervisor and have it passed accurately to the guests" has a certain
elegant simplicity about it.  But if you achieve the latter by
periodically resyncing against what the guest sees as its hardware clock
you've lost that elegance again.  It really needs to 'just work' via KVM
code in the guest kernel using the exact same time as the hypervisor
kernel is supplying.

-- 
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Synchronized time with kvm_clock

[John Buswell]

Athanasius wrote:
> On Mon, Apr 26, 2010 at 10:32:51AM -0400, John Buswell wrote:
>   
>> You don't need to run ntp on each guest. You can enable rtc support in  
>> the guest kernel and on the hypervisor. Run ntp client on the hypervisor  
>> via cron, and use hwclock -w on the hypervisor after you run ntp, to  
>> sync the hardware clock to the system clock (which is now updated by  
>> ntpdate). On the guests, periodically run hwclock -s to set the system  
>> clock from the hw clock.
>>     
>
>   What a *horribly* hacky way to do it, meaning you'll get time warps
> all over the place, admittedly of short intervals if you run those cron
> jobs often enough.  It seems much simpler to me to simply run ntpd in
> all the guests.  It's not like the extra CPU or bandwidth is going to be
> a problem.  At the very least you want to run ntpd, not ntpdate out of
> cron, in the hypervisor, and only use cron for those hwclock -w's.
Not really. You don't get time warps at all, the only place you get a 
time warp is on the initial guest, and thats not a problem with the 
workaround I suggested. It seems to be an issue with the clock on the 
initial guest. There is no point wasting resources by running ntpd on 
each guest when you don't have to.
>   
>> This seems to work extremely well, the clocksource on the guests as  
>> kvm_clock, and as long as you have the clocksource as hpet or acpi_pm on  
>> the hypervisor, there doesn't seem to be any problems with keeping time.
>>
>> The only thing I've noticed is that when you reboot, the very first  
>> guest will have the wrong time on boot, so the uptime is messed up.
>>     
>
>   And I think many people would find this unacceptable.
>   
This particular problem has nothing to do with what I suggested above. 
This is some kind of issue with kvm_clock on the first guest starting up.
>   Really, I appreciate that "keep the time sync'd via ntpd on the
> hypervisor and have it passed accurately to the guests" has a certain
> elegant simplicity about it.  But if you achieve the latter by
> periodically resyncing against what the guest sees as its hardware clock
> you've lost that elegance again.  It really needs to 'just work' via KVM
> code in the guest kernel using the exact same time as the hypervisor
> kernel is supplying.
>
>   
I agree. Unfortunately, kvm_clock doesn't seem to be quite there yet. So 
using rtc0 as a comparison, and keeping the hypervisor clock in sync 
with reality, is a good way to avoid having to run N+1 copies of ntpd on 
the guests :)

-- 
John Buswell
CEO, Carbon Mountain LLC
http://www.carbonmountain.com