From mboxrd@z Thu Jan 1 00:00:00 1970 From: Espen Berg Subject: Re: Timedrift in KVM guests after livemigration. Date: Sun, 18 Apr 2010 01:21:58 +0200 Message-ID: <4BCA4296.2080608@monsternett.no> References: <4BC6C1B1.5010206@monsternett.no> <4BCA1164.1030808@monsternett.no> <4BCA1756.6060800@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: kvm@vger.kernel.org Return-path: Received: from mail2.monsternett.no ([217.171.192.11]:37482 "EHLO mail.monsternett.no" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751866Ab0DQXWv (ORCPT ); Sat, 17 Apr 2010 19:22:51 -0400 Received: from localhost (filter.monsternett.no [217.171.192.14]) by mail.monsternett.no (Postfix) with ESMTP id 69006C09BD8B for ; Sun, 18 Apr 2010 01:22:49 +0200 (CEST) Received: from mail.monsternett.no ([217.171.192.10]) by localhost (filter.monsternett.no [217.171.192.14]) (amavisd-new, port 10024) with ESMTP id oZjOWEQHt6J2 for ; Sun, 18 Apr 2010 01:22:45 +0200 (CEST) Received: from [217.171.199.6] (ws14.monsternett.no [217.171.199.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.monsternett.no (Postfix) with ESMTPSA id C1F93C09BD84 for ; Sun, 18 Apr 2010 01:22:45 +0200 (CEST) In-Reply-To: <4BCA1756.6060800@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: Den 17.04.2010 22:17, skrev Michael Tokarev: >>> We have three KVM hosts that supports live-migration between them, but >>> one of our problems is time drifting. The three frontends has different >>> CPU frequency and the KVM guests adopt the frequency from the host >>> machine where it was first started. > What do you mean by "adopts" ? Note that the cpu frequency > means nothing for all the modern operating systems, at least > since the days of common usage of MS-DOS which relied on CPU > frequency for its time functions. All interesting things are > now done using timers instead, and timers (which don't depend > on CPU frequency again) usually work quite well. The assumption that frequency of the ticks was calculated by the hosts MHz, was based on the fact that grater clock frequency differences caused higher time drift. 60 MHz difference caused about 24min drift, 332 MHz difference caused about 2h25min drift. > What complicates things is that the most cheap and accurate > enough time source is TSC (time stamp counter register in > the CPU), but it will definitely be different on each > machine. For that, 0.12.3 kvm and 2.6.32 kernel (I think) > introduced a compensation. See for example -tdf kvm option. Ah, nice to know. :) >> Since this is a cluster in production, I'm not able to try the latest >> version either. > Well, that's difficult one, no? It either works or not. > If you can't try anything else, why to ask? :) What I tried to say was that there are many important virtual servers running on this cluster at the moment, so "trial by error" was not an option. The last time we tried 0.12.x (during the initial tests of the cluster) there where a lot of stability issues, crashes during migration etc. Regards, Espen