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

Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart



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.

Ian.

-- 
Ian Campbell
Current Noise: Trouble - Wickedness Of Man

 ok, I will not marry Jo-Con-El's cow.




Reply to: