[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [win-pv-devel] rtc timeoffset not being set on TZ changes?

  • To: Nathan March <nathan@xxxxxx>, "win-pv-devel@xxxxxxxxxxxxxxxxxxxx" <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Tue, 16 Aug 2016 08:09:39 +0000
  • Accept-language: en-GB, en-US
  • Delivery-date: Tue, 16 Aug 2016 08:10:06 +0000
  • List-id: Developer list for the Windows PV Drivers subproject <win-pv-devel.lists.xenproject.org>
  • Thread-index: AdH0wHhFsYKeTQN+Sha68LWELTALBQDuYevVAkGWdYgCeJkk6AJzPgnOnslyJeCfBKp1QA==
  • Thread-topic: [win-pv-devel] rtc timeoffset not being set on TZ changes?



  There do indeed seem to be many bugs here:


a)      QEMU (upstream) ignores time updates altogether

b)      QEMU seemingly can’t write to rtc/timeoffset even if it wanted to

c)       The timeoffset is not getting preserved on migrate


  There is one thing you could try though. Windows has an override which makes it treat the RTC as always being UTC. See http://crashmag.net/configuring-windows-7-support-for-utc-bios-time.







From: Nathan March [mailto:nathan@xxxxxx]
Sent: 15 August 2016 23:52
To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [win-pv-devel] rtc timeoffset not being set on TZ changes?


Hi Paul,


First off, apologies for the flood of messages to you and everyone on-list =)


I'm seeing a few things that make for some weird and possibly unpredictable behavior here:


1. The rtc/timeoffset value is not preserved on migration, causing a migrated VM to revert back to dom0 time

2. The xenstore rtc/timeoffset is relative to the rtc_timeoffset specified in xl.cfg (they're not the same variable)

3. Likely due to #2, specifying rtc_timeoffset in the config isn't inserted into rtc/timeoffset on create


As an example:


1. Boot windows 2012R2 on hostA, with rtc_timeoffset 0 in the config. Host and VM are set to PST. VM clock shows 3pm correctly

2. Set the VM to EST, clock is now 6pm and /vm/UUID/rtc/timeoffset is now 10800

3. Migrate the vm to hostB

4. Clock reverts back to incorrect 3pm (still on EST), and /vm/UUID/rtc/timeoffset is now null

5. Shutdown the VM completely, and recreate it with config option rtc_timeoffset 10800

6. VM boots up with correct 6pm for the configured EST time zone, and /vm/UUID/rtc/timeoffset is now null

7. Migrate to hostA, clock stays on correct timezone, rtc/timeoffset is still null


This behavior ends up effectively meaning I need to disallow migrations on any VM that has had a local time change, until I can do a restart of it to set rtc_timeoffset at creation time. It also makes the logic for handling that setting a little trickier, as I need to keep track of the two values and relative difference.


Ideally I think both xl.cfg rtc_timeoffset and xenstore rtc/timeoffset should be treated the same and handled as a single setting, but that's more open to opinion. The resetting of rtc/timeoffset to null on migration however looks like a bug.





From: Nathan March [mailto:nathan@xxxxxx]
Sent: Monday, August 15, 2016 11:34 AM
To: 'Paul Durrant' <Paul.Durrant@xxxxxxxxxx>; 'win-pv-devel@xxxxxxxxxxxxxxxxxxxx' <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
Subject: RE: [win-pv-devel] rtc timeoffset not being set on TZ changes?


Tracked this down, the default xenstore permissions don't seem to allow qemu-dm to write to it


Name                                        ID   Mem VCPUs      State   Time(s)

nathanwin                                   61  8191     2     -b----      13.6

nathanwin-dm                                62    32     1     -b----       5.5


rtc = "" . . . . . . . . . . . . . . . . . . . . . . . . . .  (n0,r61)

timeoffset = "" . . . . . . . . . . . . . . . . . . . . . .  (n0,r62)


Changing this to be writeable, makes it work.


- Nathan

win-pv-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.