[Qemu-devel] [RFC] Time resync by qemu-ga

[Qemu-devel] [RFC] Time resync by qemu-ga

[Lei Li]

Hi guys,

I am working on the time drift issue as background info here.

http://mid.gmane.org/87pq5r5otp.fsf@codemonkey.ws

As Anthony proposed, one part of the solutions is that we want
to add a qemu-ga command to resync the guest clock by reading the
wallclock time when the tick overflow the limit to the number
of missed ticks.

When I implement on the qemu-ga side, I got some problems and
I'd like to send this RFC out and ask for suggestions and comments
to make sure I am in the right direction before I send out the code.

The proposed interface for qemu-ga command as link here:

http://wiki.qemu.org/Features/GuestAgent/UsefulCommands

This maybe easier to implement, but I think this interface may
have problem, like the delta issue. So I am trying to implement
it like below.

The interface looks like:

{ 'command': 'guest-resync-time' }

The way it works:

When calling this command in the host, qemu-ga would try to
get the wallclock time in the host by handling guest->host
commands, and then write this time to the guest hardware.

But looks like we don't have the way to get host information
now, since qemu-ga just handle host->guest commands (Correct
me if I am wrong). To solve this, we should add support to
get host information by handling guest->host commands by qemu-ga
first.

Please correct me if I am wrong. And suggestions and comments
are very appreciated, specifically the way to handle quest->host
commands by qemu-ga since I am still struggling with this.

Thanks!

-- 
Lei

Re: [Qemu-devel] [RFC] Time resync by qemu-ga

[mdroth]

On Fri, Dec 28, 2012 at 12:29:15AM +0800, Lei Li wrote:
> Hi guys,
> 
> I am working on the time drift issue as background info here.
> 
> http://mid.gmane.org/87pq5r5otp.fsf@codemonkey.ws
> 
> As Anthony proposed, one part of the solutions is that we want
> to add a qemu-ga command to resync the guest clock by reading the
> wallclock time when the tick overflow the limit to the number
> of missed ticks.
> 
> When I implement on the qemu-ga side, I got some problems and
> I'd like to send this RFC out and ask for suggestions and comments
> to make sure I am in the right direction before I send out the code.
> 
> The proposed interface for qemu-ga command as link here:
> 
> http://wiki.qemu.org/Features/GuestAgent/UsefulCommands
> 
> This maybe easier to implement, but I think this interface may
> have problem, like the delta issue. So I am trying to implement
> it like below.
> 
> The interface looks like:
> 
> { 'command': 'guest-resync-time' }
> 
> The way it works:
> 
> When calling this command in the host, qemu-ga would try to
> get the wallclock time in the host by handling guest->host
> commands, and then write this time to the guest hardware.
> 
> But looks like we don't have the way to get host information
> now, since qemu-ga just handle host->guest commands (Correct
> me if I am wrong). To solve this, we should add support to
> get host information by handling guest->host commands by qemu-ga
> first.
> 
> Please correct me if I am wrong. And suggestions and comments
> are very appreciated, specifically the way to handle quest->host
> commands by qemu-ga since I am still struggling with this.

I don't think the guest actually needs to talk to the host here, it's
okay to punt some of the work to the host/management. Since we just
need to be able to set the guest time in cases where NTP is disabled, or
the guest is too far behind for the NTP clients to adjust the time (Windows
has a configurable threshold for instance), all we really need to
know to do this is the host time in UTC (which is presumably correct), and
the guest offset from that (timezone basically: UTC, UTC+4, etc.).

So to set the time we'd just need a guest-set-time interface as proposed in
the wiki, and to know what to set it to we would probably need something
like:

{'execute':'guest-get-time'}
{'seconds': 1343862720, 'nanoseconds': 123000000, 'utc-offset': -6}

the seconds/nanoseconds in this case is mostly for completeness, the
utc-offset is all we really need to translate the host time into the
appropriate guest time for the set-time command.

> 
> Thanks!
> 
> -- 
> Lei
>