On 09/09/2011 06:28 PM, al pat wrote:
We are doing an experiment with
kvm-clock to validate its effectiveness, particularly when
running NTP on the host to make sure the host’s clock stays
properly sync.
Our observations leads us to a few unanswered questions,
including the possibility of a bug (our our misunderstanding
of how kvm_clock should work).
Our understanding is that kvm_clock will help sync the clock
between the host and the guest. We do not observe this to
happen in reality and thus this question.
We are using Ubuntu 11.04 on the host and the guest.
The command we issue to launch the VM is the following:
$ sudo kvm -m 500 -rtc clock=host guestos.img
We also arranged for Ubuntu to show the seconds on the clock
displayed in the menu.
Observation 1:
Upon launching the VM, we see a time difference between the 2
clock ranging from 1 to 2 seconds.
Observation 2:
If we change the date on the host (with a command such as
“date --set 10:00:00 AM Sep 9, 2011”), the time on the guest
remains the same, unaffected.
Observation 3:
After running for a while without NTP on the host, we run
“ntpdate” to sync up the host, but the guest stick with
whatever previous time.
You probably meant "ntpd -q"
Another test we will run is to have ntpd on the host and wait
for an extended time to see if the guest drifts away from that
original 1 or 2 second lag. In the meantime, we are asking
you for some input in this regards:
Questions
-What does the “–rtc clock” option is supposed to mean
exactly? According to the man page, the guest should get its
time from the host, but neither date nor an “ntpdate” affected
the clock on the guest.
-What are the other options that we should use?
-rtc
[base=utc|localtime|date][,clock=host|vm][,driftfix=none|slew]
Specify base as "utc" or "localtime" to let the RTC
start at the
current UTC or local time, respectively. "localtime"
is required
for correct date in MS-DOS or Windows. To start at a
specific point
in time, provide date in the format
"2006-06-17T16:01:21" or
"2006-06-17". The default base is UTC.
By default the RTC is driven by the host system
time. This allows
to use the RTC as accurate reference clock inside
the guest,
specifically if the host time is smoothly following
an accurate
external reference clock, e.g. via NTP. If you want
to isolate the
guest time from the host, even prevent it from
progressing during
suspension, you can set clock to "vm" instead.
Enable driftfix (i386 targets only) if you
experience time drift
problems, specifically with Windows' ACPI HAL. This
option will try
to figure out how many timer interrupts were not
processed by the
Windows guest and will re-inject them.
Can someone shed light on what we are missing? Any pointers
will be helpful.
Thanks
-a
|