From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Buswell Subject: Re: Synchronized time with kvm_clock Date: Mon, 26 Apr 2010 13:07:37 -0400 Message-ID: <4BD5C859.4090903@carbonmountain.com> References: <201004261133.06491.alex@speakup.nl> <201004261201.38221.alex@speakup.nl> <4BD5A413.50709@carbonmountain.com> <20100426164327.GC25799@miggy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: John Buswell , Alex Hermann , kvm@vger.kernel.org Return-path: Received: from smtp.carbonmountain.com ([74.207.244.159]:37127 "EHLO smtp.carbonmountain.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751210Ab0DZRHn (ORCPT ); Mon, 26 Apr 2010 13:07:43 -0400 In-Reply-To: <20100426164327.GC25799@miggy.org> Sender: kvm-owner@vger.kernel.org List-ID: 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