From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Time and KVM - best practices Date: Mon, 22 Mar 2010 11:36:07 +0100 Message-ID: <4BA74817.8080607@siemens.com> References: <1f0fa7ae1003210429k2e958bfj1b6bd98243cefa84@mail.gmail.com> <4BA7354B.3080501@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?ISO-8859-1?Q?Thomas_L=F8cke?= , kvm@vger.kernel.org, Glauber Costa To: dlaor@redhat.com Return-path: Received: from goliath.siemens.de ([192.35.17.28]:24317 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752597Ab0CVKgZ (ORCPT ); Mon, 22 Mar 2010 06:36:25 -0400 In-Reply-To: <4BA7354B.3080501@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Dor Laor wrote: > On 03/21/2010 01:29 PM, Thomas L=F8cke wrote: >> Hey, >> >> What is considered "best practice" when running a KVM host with a >> mixture of Linux and Windows guests? >> >> Currently I have ntpd running on the host, and I start my guests usi= ng >> "-rtc base=3Dlocalhost,clock=3Dhost", with an extra "-tdf" added for >> Windows guests, just to keep their clock from drifting madly during >> load. >> >> But with this setup, all my guests are constantly 1-2 seconds behind >> the host. I can live with that for the Windows guests, as they are n= ot >=20 > Is it just during boot time? If you run ntpdate after the boot inside > the guest, does the time is 100% in sync with the host from that mome= nt on? >=20 > Glauber once analyzed it and blames hwclock call in rc.sysinit >=20 >> running anything that depends heavily on the time being set perfect, >> but for some of the Linux guests it's an issue. >> >> Would I be better of using ntpd and "-rtc base=3Dlocalhost,clock=3Dv= m" for >> all the Linux guests, or is there some other magic way of ensuring >> that the clock is perfectly in sync with the host? Perhaps there are >> some kernel configuration I can do to optimize the host for KVM? >=20 > Jan is the expert here, but last I checked clock=3Dvm is not appropri= ate > since this is virtual time and not host time - if qemu is > stopped/migrated you won't notice it with virtual time withing the gu= est > but the drift will grow. Don't know what Windows does with the RTC, but the idea behind -rtc clock=3Dhost is to provide an accurate time source to guest without paravirtualized guest kernel drivers or an ntp installation in the guest. Last time I checked, hwclock run in a Linux guest was in sync with the host system time. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux