Re: Synchronized time with kvm_clock

[John Buswell <buswellj@carbonmountain.com>]

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