[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH] [PVOPS] dom0 sync xen wallclock
On Fri, 2010-02-19 at 23:05 +0000, Jeremy Fitzhardinge wrote: > > > Unfortunately there is an existing large installed base of guests > which > > use the dependent wallclock mode since it is the default in oldstyle > Xen > > kernels. > > > > Sure. I'm not suggesting that we remove the existing hypercall. I > just don't think we should extend it or encourage its use. We currently have a large installed base of guests which use dependent wallclock and therefore expect the Xen wallclock to be correct when they start and to be remain roughly in sync thereafter (and these guests cope with the sawtoothing this implies). I think the first half of that behaviour (correct when they start) is most crucial here. As it stands the Xen wallclock time doesn't get updated for several minutes after boot because ntpdate doesn't cause a sync to the hypervisor nor hardware RTC and ntpd takes ages to decide it has syncd which means that any PV guests which start in that interval and use dependent wallclock (which is currently most) will see a large time discontinuity whenever ntpd in domain 0 is happy enough to actually sync the RTC (which as a side-effect pushes a new time into Xen) not to mention they will be running with some bogus time for that entire interval. Hooking clock_was_set fixes this issue If we choose not to include the timer aspect which keeps the hypervisor wallclock roughly in sync we need to communicate this change to. They now need to run ntpd in their guest where previously we advised the opposite (for example in http://wiki.xensource.com/xenwiki/InstallationNotes but this also impacts distro documentation and google-fu). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |