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

Re: [Xen-users] Time is off by an hour in my XEN vm



"Frank Groeneveld" wrote:

> 
> Yes, that will probably work, but it used to work without such tricks.  
> I'm sure it's just a setting in my VM or something like that.

I think to know what that issue might be, and it is most likely not a Xen 
Software problem at all, but a general virtualization issue. I had to deal with 
similar problems in the past as well and collected the following information 
from google + different other sources.

As you might know, there is a posix standard that defines any computer's RTC 
(CMOS Real Time Clock) to be UTC (or GMT or however you call it). Anyhow, as 
you probably also might or might not assume, Microsoft does not follow that 
standard and interprets the RTC as localtime (GMT +/- X). It shows +1h on your 
system, so I assume you are GMT+1 (or UTC+1). There are probably reasons for 
Microsoft doing so, even if we can't really spot them - most likely because of 
backward compatibility -who knows ;) As you can see - there is a discrepancy 
between your host, running linux, following posix, and you guest, that gets no 
own RTC from xen based on the nature of xen virtualization and therefore needs 
to share the real RTC with linux but the OS is not following posix.

There is a RealTimeIsUniversal registry flag hidden in the windows registry 
that can be set (its not in by default) to let Windows interpret the RTC as UTC 
as well.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] 
"RealTimeIsUniversal"=dword:00000001

This possibility seems to be there as a leftover from the days when NT still 
ran on RISC machines with UTC RTCs but is not even official documented anywhere 
as far as I've seen. So I would not assume that it will be there forever. The 
RTIU registry key is still active within the NT kernel for at least XP and 2003 
and works in a way to tell Windows to interpret the Hardware clock as UTC, BUT 
- only on boot time (actually the kernel seems to read that key directly, check 
the NT kernel with "strings"). So you can use that as a workaround whenever you 
run your linux host posix and windows on top. 

I have recognized that windows has another special "gotcha" you need to know 
regarding the clock that is not well documented. Windows tries to sync time 
exactly every hour (starting 1h after boot) with the hardware CMOS clock AS 
LONG AS you either don't have NTP configured or none of the configured NTP 
server(s) is reachable. In that case, the RealTimeIsUniversal key is not 
interpreted by the running OS - the reg key seems to be only used by the kernel 
itsef at boot time - you can find the string within the kernel binary - but 
nowhere else in the OS. So this may become another issue, even if you set the 
windows registry key above. As long as NTP sync is configured and any NTP 
server is reachable on bootime+1h+1h+..., Windows does not sync with CMOS 
anymore but uses the NTP as time source. As soon as I have a working NTP sync 
in place, the clock does not get set back to UTC anymore, otherwise it would 
even get set back to localtime every hour..

Another option would be to set your bios to localtime and tell linux to ignore 
the posix standard - linux deals much better with that than windows with the 
counterpart. So you would have to tell the linux xen host to interpret the RTC 
as local (check http://man.he.net/man8/clock). Most people recommend that when 
one runs windows and linux on the same host (e.g. within xen environments) as 
the best practice.

hope this helped
cheers
Ralf


_____________________________________________________________________
Unbegrenzter Speicherplatz für Ihr E-Mail Postfach? Jetzt aktivieren!
http://freemail.web.de/club/landingpage.htm/?mc=025555


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

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