Time and KVM - best practices

Time and KVM - best practices

[Thomas Løcke]

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 using
"-rtc base=localhost,clock=host", 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 not
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=localhost,clock=vm" 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?

I'm currently using QEMU PC emulator version 0.12.50 (qemu-kvm-devel)
because version 0.12.30 did not work well at all with Windows guests,
and the kernel in both host and Linux guests is 2.6.33.1

:o)
/Thomas

Re: Time and KVM - best practices

[Dor Laor]

On 03/21/2010 01:29 PM, Thomas Løcke 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 using
> "-rtc base=localhost,clock=host", 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 not

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 moment on?

Glauber once analyzed it and blames hwclock call in rc.sysinit

> 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=localhost,clock=vm" 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?

Jan is the expert here, but last I checked clock=vm is not appropriate 
since this is virtual time and not host time - if qemu is 
stopped/migrated you won't notice it with virtual time withing the guest 
but the drift will grow.

>
> I'm currently using QEMU PC emulator version 0.12.50 (qemu-kvm-devel)
> because version 0.12.30 did not work well at all with Windows guests,
> and the kernel in both host and Linux guests is 2.6.33.1
>
> :o)
> /Thomas
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Time and KVM - best practices

[Alexander Graf]

On 22.03.2010, at 10:15, Dor Laor wrote:

> On 03/21/2010 01:29 PM, Thomas Løcke 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 using
>> "-rtc base=localhost,clock=host", 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 not
> 
> 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 moment on?
> 
> Glauber once analyzed it and blames hwclock call in rc.sysinit

In fact, my kvm-clock based guests lag about 1 second behind as well. I suppose there's some compensation code that doesn't work correctly.

Alex

Re: Time and KVM - best practices

[Jan Kiszka]

Dor Laor wrote:
> On 03/21/2010 01:29 PM, Thomas Løcke 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 using
>> "-rtc base=localhost,clock=host", 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 not
> 
> 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 moment on?
> 
> Glauber once analyzed it and blames hwclock call in rc.sysinit
> 
>> 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=localhost,clock=vm" 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?
> 
> Jan is the expert here, but last I checked clock=vm is not appropriate
> since this is virtual time and not host time - if qemu is
> stopped/migrated you won't notice it with virtual time withing the guest
> but the drift will grow.

Don't know what Windows does with the RTC, but the idea behind -rtc
clock=host 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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Time and KVM - best practices

[Thomas Løcke]

On Mon, Mar 22, 2010 at 11:36 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Don't know what Windows does with the RTC, but the idea behind -rtc
> clock=host 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.

This is not the case with a 2.6.33.1 host and 2.6.33.1 guests. The clock drifts.

Using -rtc base=localtime,clock=host and no ntpd in guest: Clock
starts out ~1 second behind host. After a few days of uptime, the
guest clock is now ahead of host with ~7 seconds.

Using -rtc base=localtime,clock=vm and ntpd in guest: Clock starts out
~1 second behind host. After a few days of uptime, the guest clock is
in perfect sync with host clock.

I'm currently using qemu-kvm 0.12.50, as that version is much better
in regards to keeping time in my Windows guests than 0.12.30. IFAIK
there are no differences between 0.12.30 and 0.12.50 and time-keeping
in Linux guests. They seem to act similar.

I've tried the following kernels for both host and guests: 2.6.29.6,
2.6.33 and 2.6.33.1. They all exhibit the same behavior. I've used the
stock Slackware kernel config for all the kernels. Can it be that
Slackware is missing some crucial kernel setting to manage time
"correct" in relation to KVM?

Regards,
/Thomas

Re: Time and KVM - best practices

[Glauber Costa]

On Mon, Mar 22, 2010 at 10:55:18AM +0100, Alexander Graf wrote:
> 
> On 22.03.2010, at 10:15, Dor Laor wrote:
> 
> > On 03/21/2010 01:29 PM, Thomas Løcke 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 using
> >> "-rtc base=localhost,clock=host", 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 not
> > 
> > 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 moment on?
> > 
> > Glauber once analyzed it and blames hwclock call in rc.sysinit
> 
> In fact, my kvm-clock based guests lag about 1 second behind as well. I suppose there's some compensation code that doesn't work correctly.
The problem I found, is that we read wallclock information from kvm host, but later on boot,
we call the hwclock binary, which adjusts things as it sees fit. So in this scenario, kvmclock wallclock
time is just not being used at all.