Question on kvm_clock working ...

Question on kvm_clock working ...

[al pat]

[-- 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 --]

[Qemu-devel] Question on kvm_clock working ...

[al pat]

[-- 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 --]

Re: [Qemu-devel] Question on kvm_clock working ...

[al pat]

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

Hi Folks,

Still seeking your guidance on this. Appreciate any pointers you may have.

Thanks much.
-a

On Fri, Sep 9, 2011 at 11:28 AM, al pat <alps.oss@gmail.com> 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.
>
>
> 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: 3949 bytes --]

Re: [Qemu-devel] Question on kvm_clock working ...

[Philipp Hahn]

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

Hello Al,

I just debugged a kvmclock bug, so I claim to have some knowledge in this area 
now, but please take my answer with a grain of doubt.

On Monday 12 September 2011 15:21:25 al pat wrote:
> Still seeking your guidance on this. Appreciate any pointers you may have.

You have to distiguish between the real-time-clock (RTC), which in hardware is 
a battery powered clock running even when your PC is powered off. Since it's 
slow to access, most Linux distributions read out its value once during boot 
using "hwclock --hctosys --utc" and than don't care about that clock any more 
until shutdown, when they write back the system time to the RTC 
using "... --systohc ...".
During runtime, other methods are used for time keeping: Either by counting 
regular interrupts, using the ACPI-PM clock, or the High Performance Event 
Timer (HPET), or the Time Stamp Counter (TSC) register, or ...; 
see /sys/devices/system/clocksource/clocksource0/available_clocksource for a 
list of available clock sources.

For virtual machines there is an additional clock source named "kvmclock", 
which uses the host clock and the TSC: The host exports its current system 
time (plus some configurable offset) and a snapshot value of TSC register 
when doing so. Than the guest can interpolate the current time by using the 
exported_system_time + scale * (current_TSC_value-snapshot_TSC_value). This 
kvmclock doesn't have anything to do with the RTC clock as far as I know.

Now to your problem: You should check the value 
of /sys/devices/system/clocksource/clocksource0/current_clocksource in your 
guest. If it is somethong other than kvmclock, you should if 
using "hwclock --hctosys --utc" re-synchronizes your guest clock to the host.

Sincerely
Philipp
-- 
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/
----------------------------------------------------------------------------
Treffen Sie Univention auf der IT&Business vom 20. bis 22. September 2011
auf dem Gemeinschaftsstand der Open Source Business Alliance in Stuttgart in
Halle 3 Stand 3D27-7.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Qemu-devel] Question on kvm_clock working ...

[al pat]

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

Thanks Phillip.

My current source is "kvm-clock".

WHen I start my guest, it is in sync with the host clock.

Then, I chance the time on my host - using "date --set ...". I don't see the
guest update its time.
I was expecting that the guest will detect host time change and change it?

So, when the host is exporting its system time and TSC values, does it go
into the "emulated RTC" of the guest and the guest checks it only once? Or
does the guest resync its clock with the host's value periodically?

I can try to do: "hwclock --hctosys --utc" --- this is just to check. (I
have kvm-clock as my clock source though).

Thanks
-a

On Tue, Sep 13, 2011 at 2:49 AM, Philipp Hahn <hahn@univention.de> wrote:

> Hello Al,
>
> I just debugged a kvmclock bug, so I claim to have some knowledge in this
> area
> now, but please take my answer with a grain of doubt.
>
> On Monday 12 September 2011 15:21:25 al pat wrote:
> > Still seeking your guidance on this. Appreciate any pointers you may
> have.
>
> You have to distiguish between the real-time-clock (RTC), which in hardware
> is
> a battery powered clock running even when your PC is powered off. Since
> it's
> slow to access, most Linux distributions read out its value once during
> boot
> using "hwclock --hctosys --utc" and than don't care about that clock any
> more
> until shutdown, when they write back the system time to the RTC
> using "... --systohc ...".
> During runtime, other methods are used for time keeping: Either by counting
> regular interrupts, using the ACPI-PM clock, or the High Performance Event
> Timer (HPET), or the Time Stamp Counter (TSC) register, or ...;
> see /sys/devices/system/clocksource/clocksource0/available_clocksource for
> a
> list of available clock sources.
>
> For virtual machines there is an additional clock source named "kvmclock",
> which uses the host clock and the TSC: The host exports its current system
> time (plus some configurable offset) and a snapshot value of TSC register
> when doing so. Than the guest can interpolate the current time by using the
> exported_system_time + scale * (current_TSC_value-snapshot_TSC_value). This
> kvmclock doesn't have anything to do with the RTC clock as far as I know.
>
> Now to your problem: You should check the value
> of /sys/devices/system/clocksource/clocksource0/current_clocksource in your
> guest. If it is somethong other than kvmclock, you should if
> using "hwclock --hctosys --utc" re-synchronizes your guest clock to the
> host.
>
> Sincerely
> Philipp
> --
> Philipp Hahn           Open Source Software Engineer
> hahn@univention.de
> Univention GmbH        Linux for Your Business        fon: +49 421 22 232-
> 0
> Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22
> 232-99
>
> http://www.univention.de/
>
> ----------------------------------------------------------------------------
> Treffen Sie Univention auf der IT&Business vom 20. bis 22. September 2011
> auf dem Gemeinschaftsstand der Open Source Business Alliance in Stuttgart
> in
> Halle 3 Stand 3D27-7.
>

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

Re: [Qemu-devel] Question on kvm_clock working ...

[Jan Kiszka]

On 2011-09-13 13:38, al pat wrote:
> Thanks Phillip.
> 
> My current source is "kvm-clock".
> 
> WHen I start my guest, it is in sync with the host clock.
> 
> Then, I chance the time on my host - using "date --set ...". I don't see the
> guest update its time.
> I was expecting that the guest will detect host time change and change it?

That's not what kvmclock is supposed to provide. Besides a monotonic
clock source, it basically offers an alternative persistent clock, to
some degree replacing the emulated RTC. So updates of the host system
time are only recognized by the guest kernel when it reboots or
suspends/resumes.

> 
> So, when the host is exporting its system time and TSC values, does it go
> into the "emulated RTC" of the guest and the guest checks it only once? Or
> does the guest resync its clock with the host's value periodically?
> 
> I can try to do: "hwclock --hctosys --utc" --- this is just to check. (I
> have kvm-clock as my clock source though).

Re-reading the RTC is a brute-force approach to re-synchronize with the
host. If potential clock jumps are OK for your use case, you can go that
way.

Alternatives are using NTP against a time server or writing a RTC plugin
for NTP to synchronize against that local source (a colleague once wrote
such a plugin for a special guest, but it never made it into public AFAIK).

Jan

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

Re: [Qemu-devel] Question on kvm_clock working ...

[al pat]

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

Hi Phil,

Thanks for an excellent explanation.

Follow up question - " ...additional clock source named "kvmclock",
which uses the host clock and the TSC: The host exports its current system
time (plus some configurable offset) and a snapshot value of TSC register
when doing so. Than the guest can interpolate the current time by using the
exported_system_time + scale * (current_TSC_value-snapshot_TSC_value).
This kvmclock doesn't have anything to do with the RTC clock as far as I
know."

Question: Since I am changing time on host using "date --set ...", it should
change
the value of the host clock, no? My question was since the host clock is
changed,
by the above logic, why is the guest clock also not changing?

My current source is kvmclock.

Thanks
-a

On Tue, Sep 13, 2011 at 2:49 AM, Philipp Hahn <hahn@univention.de> wrote:

> Hello Al,
>
> I just debugged a kvmclock bug, so I claim to have some knowledge in this
> area
> now, but please take my answer with a grain of doubt.
>
> On Monday 12 September 2011 15:21:25 al pat wrote:
> > Still seeking your guidance on this. Appreciate any pointers you may
> have.
>
> You have to distiguish between the real-time-clock (RTC), which in hardware
> is
> a battery powered clock running even when your PC is powered off. Since
> it's
> slow to access, most Linux distributions read out its value once during
> boot
> using "hwclock --hctosys --utc" and than don't care about that clock any
> more
> until shutdown, when they write back the system time to the RTC
> using "... --systohc ...".
> During runtime, other methods are used for time keeping: Either by counting
> regular interrupts, using the ACPI-PM clock, or the High Performance Event
> Timer (HPET), or the Time Stamp Counter (TSC) register, or ...;
> see /sys/devices/system/clocksource/clocksource0/available_clocksource for
> a
> list of available clock sources.
>
> For virtual machines there is an additional clock source named "kvmclock",
> which uses the host clock and the TSC: The host exports its current system
> time (plus some configurable offset) and a snapshot value of TSC register
> when doing so. Than the guest can interpolate the current time by using the
> exported_system_time + scale * (current_TSC_value-snapshot_TSC_value). This
> kvmclock doesn't have anything to do with the RTC clock as far as I know.
>
> Now to your problem: You should check the value
> of /sys/devices/system/clocksource/clocksource0/current_clocksource in your
> guest. If it is somethong other than kvmclock, you should if
> using "hwclock --hctosys --utc" re-synchronizes your guest clock to the
> host.
>
> Sincerely
> Philipp
> --
> Philipp Hahn           Open Source Software Engineer
> hahn@univention.de
> Univention GmbH        Linux for Your Business        fon: +49 421 22 232-
> 0
> Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22
> 232-99
>
> http://www.univention.de/
>
> ----------------------------------------------------------------------------
> Treffen Sie Univention auf der IT&Business vom 20. bis 22. September 2011
> auf dem Gemeinschaftsstand der Open Source Business Alliance in Stuttgart
> in
> Halle 3 Stand 3D27-7.
>

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

Re: Question on kvm_clock working ...

[Ronen Hod]

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

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
>


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

Re: [Qemu-devel] Question on kvm_clock working ...

[Ronen Hod]

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

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
>


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