From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8FHH-0000zQ-E0 for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:47:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8FHG-0006o0-3W for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:47:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8FHF-0006m3-Qu for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:47:38 -0400 Message-ID: <4E80BAB0.6070104@redhat.com> Date: Mon, 26 Sep 2011 20:47:28 +0300 From: Ronen Hod MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050004090207080807090207" Subject: Re: [Qemu-devel] Question on kvm_clock working ... List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: al pat Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org This is a multi-part message in MIME format. --------------050004090207080807090207 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id p8QHlXPc016632 On 09/09/2011 06:28 PM, al pat wrote: > > We are doing an experiment with kvm-clock to validate its=20 > effectiveness, particularly when running NTP on the host to make sure=20 > the host=E2=80=99s clock stays properly sync. > Our observations leads us to a few unanswered questions, including the=20 > possibility of a bug (our our misunderstanding of how kvm_clock should=20 > work). > > Our understanding is that kvm_clock will help sync the clock between=20 > the host and the guest. We do not observe this to happen in reality=20 > 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=3Dhost guestos.img > > We also arranged for Ubuntu to show the seconds on the clock displayed=20 > in the menu. > > Observation 1: > Upon launching the VM, we see a time difference between the 2 clock=20 > ranging from 1 to 2 seconds. > > Observation 2: > If we change the date on the host (with a command such as =E2=80=9Cdate= --set=20 > 10:00:00 AM Sep 9, 2011=E2=80=9D), the time on the guest remains the sa= me,=20 > unaffected. > > Observation 3: > After running for a while without NTP on the host, we run =E2=80=9Cntpd= ate=E2=80=9D to=20 > 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=20 > extended time to see if the guest drifts away from that original 1 or=20 > 2 second lag. In the meantime, we are asking you for some input in=20 > this regards: > Questions > -What does the =E2=80=9C=E2=80=93rtc clock=E2=80=9D option is supposed = to mean exactly?=20 > According to the man page, the guest should get its time from the=20 > host, but neither date nor an =E2=80=9Cntpdate=E2=80=9D affected the cl= ock on the guest. > -What are the other options that we should use? > > -rtc [base=3Dutc|localtime|date][,clock=3Dhost|vm][,driftfix=3Dn= one|slew] > Specify base as "utc" or "localtime" to let the RTC start at = the > current UTC or local time, respectively. "localtime" is requi= red > for correct date in MS-DOS or Windows. To start at a=20 > 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=20 > allows > to use the RTC as accurate reference clock inside the guest, > specifically if the host time is smoothly following an accura= te > external reference clock, e.g. via NTP. If you want to=20 > isolate the > guest time from the host, even prevent it from progressing=20 > during > suspension, you can set clock to "vm" instead. > > Enable driftfix (i386 targets only) if you experience time dr= ift > problems, specifically with Windows' ACPI HAL. This option=20 > will try > to figure out how many timer interrupts were not processed=20 > by the > Windows guest and will re-inject them. > > > Can someone shed light on what we are missing? Any pointers will be=20 > helpful. > > Thanks > -a > --------------050004090207080807090207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id p8QHlXPc016632 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=E2=80=99s clock s= tays 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.
=C2=A0
The command we issue to launch the VM is the following:
=C2=A0
$ sudo kvm -m 500 -rtc clock=3Dhost guestos.img
=C2=A0
We also arranged for Ubuntu to show the seconds on the clock displayed in the menu.
=C2=A0
Observation 1:
Upon launching the VM, we see a time difference between the 2 clock ranging from 1 to 2 seconds.
=C2=A0
Observation 2:
If we change the date on the host (with a command such as =E2=80=9Cdate --set 10:00:00 AM Sep 9, 2011=E2=80=9D), the time= on the guest remains the same, unaffected.
=C2=A0
Observation 3:
After running for a while without NTP on the host, we run =E2=80=9Cntpdate=E2=80=9D to sync up the host, but the guest st= ick with whatever previous time.

You probably meant "ntpd -q"

=C2=A0
=C2=A0
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 =C2=A02 second lag. In the meantime, we are askin= g you for some input in this regards:
Questions
-What does the =E2=80=9C=E2=80=93rtc clock=E2=80=9D option is s= upposed to mean exactly? =C2=A0According to the man page, the guest should get = its time from the host, but neither date nor an =E2=80=9Cntpdate=E2= =80=9D affected the clock on the guest.
-What are the other options that we should use?
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-rtc [base=3Dutc|localtime|date][,clock=3Dhost|vm][,driftfix=3Dnone|= slew]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Spe= cify base as "utc" or "localtime" to let the RTC start at the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cur= rent UTC or local time, respectively. "localtime" is required
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0for= correct date in MS-DOS or Windows. To start at a specific point
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0in = time, provide date in the format "2006-06-17T16:01:21" or
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0"2006-06-17". The default base is UTC.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0By = default the RTC is driven by the host system time. This allows
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0to = use the RTC as accurate reference clock inside the guest,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0spe= cifically if the host time is smoothly following an accurate
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ext= ernal reference clock, e.g. via NTP. =C2=A0If you want to isolate the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0gue= st time from the host, even prevent it from progressing during
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0sus= pension, you can set clock to "vm" instead.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ena= ble driftfix (i386 targets only) if you experience time drift
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pro= blems, specifically with Windows' ACPI HAL. This option will try
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0to = figure out how many timer interrupts were not processed by the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Win= dows guest and will re-inject them.
=C2=A0
=C2=A0
Can someone shed light on what we are missing? Any pointers will be helpful.

Thanks
-a
=C2=A0
=C2=A0

--------------050004090207080807090207--