On Mon, Mar 22, 2010 at 11:36 AM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
