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

 

Cheers,

Nathan

 

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
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel

 


Rackspace

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