From owner-freebsd-xen@FreeBSD.ORG Wed Jan 14 20:57:03 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04210747 for ; Wed, 14 Jan 2015 20:57:03 +0000 (UTC) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id D03869D6 for ; Wed, 14 Jan 2015 20:57:02 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 8E63D30862 for ; Wed, 14 Jan 2015 15:48:47 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEHS45T76q1s for ; Wed, 14 Jan 2015 15:48:47 -0500 (EST) Received: from EGR authenticated sender Message-ID: <54B6D62F.9090002@egr.msu.edu> Date: Wed, 14 Jan 2015 15:48:47 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-xen@freebsd.org Subject: Re: XenServer 6.5 migrate FBSD 10/11 results in clock reset to 1970? References: <70A0A91F47C63040B165812D@[10.12.30.106]> <1421268127.1109646.213984377.0E5EC646@webmail.messagingengine.com> In-Reply-To: <1421268127.1109646.213984377.0E5EC646@webmail.messagingengine.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 20:57:03 -0000 On 01/14/2015 15:42, Mark Felder wrote: > > > On Wed, Jan 14, 2015, at 09:16, Karl Pielorz wrote: >> >> Hi, >> >> This has been seen before e.g. see >> >> >> >> We're now seeing this now we've started using 10.x boxes under XenServer >> 6.5 >> >> Is there any work around for it? >> >> The 'hit' rate for us seems to be quite high (+70%?) i.e. the clock >> resets >> most of the time we do even just a storage migration. >> >> The guests are running NTP - and that continues running after the event, >> but is obviously unwilling to make such a big clock adjustment to drag >> the >> guests time from 1970 to present day. >> >> Unfortunately - this also causes various other things on the box to break >> as well :( >> >> Is there no 'after migration' hook or script I can lodge some code to >> shutdown NTP, do an ntpdate - then restart NTP again? >> > > When I ran into this I manually stopped NTP, migrated, ran ntpdate, > started NTP again. It was painful. > > The problem as I recall is in the PVHVM code and is fixed upstream in > Xen but wasn't pulled into XenServer. Roger will know more details, but > if you have a Citrix support contract you should pressure them to open a > bug / regression on this. Unfortunately I'm no longer in a position to > do so... > _______________________________________________ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" > I really thought this was fixed in Creedence alphas that I tested... I still have those test systems up but I need to make a test environment for 6.5. Are you using AMD or Intel? I don't know if it makes a difference but I've only seen the problem on AMD so far.