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

[Roger Pau Monné]

El 14/01/15 a les 21.42, Mark Felder ha escrit:
> 
> 
> 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...

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:

http://www.chiark.greenend.org.uk/~xensrcts/logs/33395/test-amd64-i386-freebsd10-amd64/14.ts-guest-localmigrate.log

After each migration the date inside of the guest is printed in order to
make sure no skew happens.

Roger.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

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

[Karl Pielorz]

--On 14 January 2015 18:06:51 -0500 Adam McDougall  
wrote:



Are you sure you are running 6.5 and not 6.2?  The guest's kernel should
detect Xen 4.4 instead of 4.1.  6.5 is Creedence but it was called
Creedence during the long alpha stage before it became 6.5.


Sorry - my mistake (Coffee is wearing off this time of night) - doesn't 
help I've seen 'next' XenServer called 7 at some point :)


We're running 6.2 - *not* 6.5...

-Karl



___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

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

[Adam McDougall]

On 01/14/2015 17:46, Karl Pielorz wrote:
> 
> --On 14 January 2015 15:48:47 -0500 Adam McDougall
>  wrote:
> 
>> 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.
> 
> We're looking at getting a Creedence test setup soon, so I can re-test
> then - at the moment our platform is XenServer 6.5 - with HP Proliant
> DL320e's (all Intel / Haswell based).
> 
> I'll check tomorrow to see how far off having a Creedence test setup
> will be.
> 
> -Karl

Are you sure you are running 6.5 and not 6.2?  The guest's kernel should
detect Xen 4.4 instead of 4.1.  6.5 is Creedence but it was called
Creedence during the long alpha stage before it became 6.5.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

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

[Karl Pielorz]

--On 14 January 2015 15:48:47 -0500 Adam McDougall  
wrote:



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.


We're looking at getting a Creedence test setup soon, so I can re-test then 
- at the moment our platform is XenServer 6.5 - with HP Proliant DL320e's 
(all Intel / Haswell based).


I'll check tomorrow to see how far off having a Creedence test setup will 
be.


-Karl
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Re: 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
>>
>>  
>>
>> 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-unsubscr...@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.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

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

[Mark Felder]

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-unsubscr...@freebsd.org"

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

[Karl Pielorz]

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?


Cheers,

-Karl
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"