[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: "'Paul Durrant'" <Paul.Durrant@xxxxxxxxxx>, <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Nathan March" <nathan@xxxxxx>
  • Date: Mon, 15 Aug 2016 15:52:26 -0700
  • Delivery-date: Mon, 15 Aug 2016 22:52:38 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gt.net; h=from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type; q=dns; s=mail; b=RgEwg2I3p5WnnYCAXG12IJxV9eOzj7RaHN3CMsh9QsslKe lSJ7RcWt2VW2gyDUcKZlqidiXs2UyXkbOnkJEuVokG1t4UoFfaHILPAJnOs5az6I bsmbTGGPrPLUnxUYZweJq+UvpeynEOyD7XoJtBJ6ycNCrralEfCqX/eiDA+5w=
  • List-id: Developer list for the Windows PV Drivers subproject <win-pv-devel.lists.xenproject.org>
  • Thread-index: AQJyE/aITnqlC5MIvRaIBdKX7biwzgDuYevVAkGWdYgCeJkk6AJzPgnOnslyJeA=

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®.