All of lore.kernel.org
 help / color / mirror / Atom feed
From: al pat <alps.oss@gmail.com>
To: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Question on kvm_clock working ...
Date: Fri, 9 Sep 2011 11:28:33 -0400	[thread overview]
Message-ID: <CAF9p440k3AJ9rBCmZDu-gwF8gOc3Tr3VNDAhL00YOMWJ48W9hQ@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2955 bytes --]

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.


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

[-- Attachment #2: Type: text/html, Size: 3494 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: al pat <alps.oss@gmail.com>
To: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Question on kvm_clock working ...
Date: Fri, 9 Sep 2011 11:28:33 -0400	[thread overview]
Message-ID: <CAF9p440k3AJ9rBCmZDu-gwF8gOc3Tr3VNDAhL00YOMWJ48W9hQ@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2955 bytes --]

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.


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

[-- Attachment #2: Type: text/html, Size: 3494 bytes --]

             reply	other threads:[~2011-09-09 15:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09 15:28 al pat [this message]
2011-09-09 15:28 ` [Qemu-devel] Question on kvm_clock working al pat
2011-09-12 13:21 ` al pat
2011-09-13  6:49   ` Philipp Hahn
2011-09-13 11:38     ` al pat
2011-09-13 13:08       ` Jan Kiszka
2011-09-15 13:48     ` al pat
2011-09-26 17:47 ` Ronen Hod
2011-09-26 17:47   ` [Qemu-devel] " Ronen Hod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAF9p440k3AJ9rBCmZDu-gwF8gOc3Tr3VNDAhL00YOMWJ48W9hQ@mail.gmail.com \
    --to=alps.oss@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.