Re: Synchronized time with kvm_clock

John Buswell
2010-04-26T17:07:43Z

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