El 14/01/15 a les 21.42, Mark Felder ha escrit:
> On Wed, Jan 14, 2015, at 09:16, Karl Pielorz wrote:
>> This has been seen before e.g. see
>> We're now seeing this now we've started using 10.x boxes under XenServer
>> Is there any work around for it?
>> The 'hit' rate for us seems to be quite high (+70%?) i.e. the clock
>> 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
>> 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...
As Mark says this has already been fixed in Xen upstream, and the fix
should be present at least in Xen 4.4 and the upcoming Xen 4.5. The Xen
continuous test system also tests each Xen commit against FreeBSD 10.1,
which includes performing x10 migrations in a row:
After each migration the date inside of the guest is printed in order to
make sure no skew happens.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"