XenServer 6.5 migrate FBSD 10/11 results in clock reset to 1970?

[Adam McDougall]

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
>>
>>  <https://lists.freebsd.org/pipermail/freebsd-xen/2013-December/001825.html>
>>
>> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-xen
> To unsubscribe, send any mail to "freebsd-xen-unsubscribe at 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.