Xen project Mailing List

Nathan,

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.

Cheers,

Paul

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.

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

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