qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Erik Rull <erik.rull@rdsoftware.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Missing guest clock-sync on Host clock change
Date: Thu, 27 Mar 2014 21:40:04 +0100	[thread overview]
Message-ID: <53348CA4.9030406@redhat.com> (raw)
In-Reply-To: <5334869D.50707@rdsoftware.de>

On 03/27/14 21:14, Erik Rull wrote:
> Laszlo Ersek wrote:
>> On 03/27/14 09:41, Erik Rull wrote:
>>> Hi all,
>>>
>>> I would like to have the guest "drifting" to a new set clock on the
>>> host.
>>>
>>> My problem is the following:
>>>
>>> - Host System (Linux) starts up, hwclock and kernel time are synced,
>>> guest starts up with -rtc clock=host,driftfix=slew (which I assume
>>> should fix any drift issue on ACPI compatible guest OSes)
>>> - Host System kernel time drifts against the hwclock (jiffies timer due
>>> to no other available useful timer on SMP systems - core2duo has no
>>> hpet!)
>>> - calling "hwclock -s" on the host resyncs the kernel time with the
>>> hwclock, so "date" and "hwclock" show the same again
>>> - the guest stays at the "old" kernel time before the sync - also after
>>> 1 hour the delta is still the same, so no sync or slew is done :-(
>>>
>>> My guest OS is Windows 8, which must have ACPI enabled, otherwise it
>>> will not work.
>>>
>>> Any ideas how to proceed? Maybe some command line parameters are wrong?
>>>
>>> I need this resync for the guest due to external synchronization - it
>>> must not be millisecond-precise, but a 9 seconds shift during a run
>>> overnight is too much!
>>
>> My take: the hardware clock (the RTC) in the guest has correct value,
>> but the guest OS system time os not refreshed from it. Install the guest
>> agent in Windows, and call its "guest-set-time" command (with virsh
>> qemu-agent-command, or otherwise). Do not pass any argument for the
>> optional "time" parameter; this way the guest will sync its kernel time
>> from its RTC.
>>
>> See:
>> - qga/qapi-schema.json, "guest-set-time",
>> - qga/commands-win32.c, qmp_guest_set_time()
>>
>> In any case this is just a guess.
>>
>> Laszlo
>>
> 
> Hi Laszlo,
> 
> thanks, I will try that, but might take some time, because the changes
> for the qemu-ga are bigger to activate. Is there a possiblity to set the
> RTC of the guest automatically in sync with the host hardware RTC? I
> didn't find a parameter for that.

Again, I have no clue, but my impression is that the guest's RTC is
already OK.

However, same as on Linux, the RTC and the system time are independent,
likely in Windows too, unless you sync them somehow periodically. You
need the equivalent of "hwclock --hctosys" in the Windows guest (which
the qga command provides for you), otherwise processes in the Windows
guest won't see the correct time (they don't care about the RTC, same as
Linux processes don't.)

Laszlo

      reply	other threads:[~2014-03-27 20:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27  8:41 [Qemu-devel] Missing guest clock-sync on Host clock change Erik Rull
2014-03-27  9:43 ` Laszlo Ersek
2014-03-27 20:14   ` Erik Rull
2014-03-27 20:40     ` Laszlo Ersek [this message]

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=53348CA4.9030406@redhat.com \
    --to=lersek@redhat.com \
    --cc=erik.rull@rdsoftware.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).