Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
On Wed, Oct 06, 2010 at 11:47:05AM +0100, Ian Campbell wrote:
> On Wed, 2010-10-06 at 09:33 +0100, Mark Adams wrote:
> > Hi Ben, Thanks for your response. See my responses inline.
> >
> > On Wed, Oct 06, 2010 at 03:35:23AM +0100, Ben Hutchings wrote:
> > > On Tue, 2010-10-05 at 09:31 +0100, Mark Adams wrote:
> > > > Package: xen-linux-system-2.6.32-5-xen-amd64
> > > > Version: 2.6.32-21
> > > > Severity: important
> > > >
> > > >
> > > > Hi, Did you receive this bug report? I hadn't received a bug ID even
> > > > though receiving the copy of the original report.
> > >
> > > We don't have any other bug report with this description.
> > >
> > > > Likely because the address it was sent from originally was invalid.
> > >
> > > That would explain it.
> > >
> > > > -----------------
> > > >
> > > > Hi All,
> > > >
> > > > Im running Xen 4.0.1-rc6 Debian squeeze with pvops 2.6.32-21 kernel.
> > > > Today I noticed (when kerberos to the domain controllers stopped
> > > > working..) that the clock was 50 minutes out in dom0 -- This caused the
> > > > HVM windows domain controllers to have the wrong time.
> > >
> > > Since you appear to be in the UK, is it possible that the real-time
> > > clock is set to local time (GMT+1) while Xen expects it to be GMT, or
> > > vice versa?
> >
> > The clock is set with tzdata as BST yes, it is also set to this in the
> > Windows server 2008 domU. We are using localtime=1 to match the clock
> > in dom0 to domU.
> >
> > >
> > > (This doesn't explain why it's 50 minutes out rather than 1 hour. But
> > > ntpd will refuse to correct a large difference and the local clock may
> > > then drift further.)
> > >
> > > [...]
> > > > Can anyone confirm whether xen controls the time or the kernel? Also
> > > > when I corrected the time in dom0 it was still wrong in HVM domU -- How
> > > > long does it take for this to propogate? (I rebooted the VM's to correct
> > > > it immediately).
> > > [...]
> > >
> > > For HVM guests, the hypervisor emulates a standard PC real-time clock
> > > and the guest uses that to initialise the system time, but there is no
> > > way to force an update after the guest has booted unless the guest has
> > > specific support for Xen; I assume Citrix does provide such software for
> > > Windows but I don't know whether it is free software.
> >
> > The citrix WHQL drivers might have this functionality, I don't use them
> > though - prefer the GPL PV drivers! (which don't have any clock support
> > as far as I can tell)
>
> I think you can run a regular NTP client (assuming one exists for
> Windows) in an HVM guest to keep wallclock time in sync.
>
> > > For PV guests, I assume you can force an update to the guest time using
> > > the Xen management tools.
> > >
> > > Note, I'm just a general kernel maintainer and don't have any great
> > > knowledge of Xen.
>
> I should know but time handling (particularly for HVM guests) is
> something where I basically know enough to know that there is lots I
> don't know ;-)
>
> Mark, you may find you get better answers/support from the xen-users
> mailing list, or failing that, xen-devel.
>
> > All good, I have a feeling it might be a kernel issue rather than xen,
> > but I'm still not sure what actually -controls- the time, is it the
> > kernel? I think the key is in the log
> >
> > Oct 2 18:50:33 havhost1 kernel: [623480.977748] Clocksource tsc unstable (delta = -2999660303788 ns)
> > >
> > As this is when the clock went from 18:00 to 18:50 and started the chain
> > of events (restarted the 2008 domU). Any ideas why this log occurred?
>
> The TSC appeared to go backwards by a fairly significant amount, which
> has upset the kernel.
>
> The behaviour of the virtual TSC as seen by an HVM guest is controlled
> by a combination of the tsc_mode setting in your domain configuration
> and, I think, by the features of your specific hardware (some have
> constant rate TSC, others advertise varying levels of synchronisation
> between cores etc). It's then up to the guest kernel whether it even
> uses TSC as a timesource at all and how it handles instability etc and
> how it derives other time sources (such as the wallclock time) from it.
>
> Sorry this isn't more helpful, but as I say you will probably get better
> answers on one of the Xen mailing lists.
Hi Ian,
Thanks for your notes. I've already tried the xen-users list so I will
try xen-devel to see if I can glean any more information about my issue.
I will update the report here when I get any more information.
Thanks,
Mark
>
> Ian.
>
> --
> Ian Campbell
> Current Noise: Trouble - Wickedness Of Man
>
> ok, I will not marry Jo-Con-El's cow.
>
Reply to: