Xen - Issues with Windows DomU client clocks

Time is off by an hour in my XEN vm

Quote:

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

Summary:

The ultimate solution is to probably run an NTP client under the Windows environment to force the software clock to slave properly.

Xen plans

So as I wait for parts to be delivered for the Test SAN unit, I'm reading up on Xen and iSCSI and debating what my plan of attack will be. My options (roughly) are:

1) Build a normal Gentoo server and load iscsitarget on top of it. This is the simplest of all options and something that I'm very comfortable with. However, if I were then then need to run other services on top of the unit, I run the risk of making the iSCSI server portion unstable.

2) Xen with various services running in DomUs. A bit more complex but offers a lot more flexibility. I can start setting up virtual servers for the sub-tasks and then migrate them off of the test unit when I have more hardware available.

What I'm not sure is whether to run iscsitarget in its own DomU or if it should run in Dom0. If I run the iscsitarget in its own DomU, then it becomes easy to restart the iscsitarget server in a worst case without taking down the entire box.

Links:

Infrastructure virtualisation with Xen advisory