"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
|
Home