Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Nov 2015 18:56:30 +0100
From:      Karl Pielorz <kpielorz_lst@tdx.co.uk>
To:        =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, freebsd-xen@freebsd.org
Subject:   Re: 'Live' Migrate messes up NTP on FreeBSD domU - any suggestions?
Message-ID:  <84EFB0608568EE976A48039C@Mac-mini.local>
In-Reply-To: <5637A01B.1010307@citrix.com>
References:  <151F73F1EF071C3C48F17866@[10.12.30.106]> <5637A01B.1010307@citrix.com>

next in thread | previous in thread | raw e-mail | index | archive | help


--On 2 November 2015 at 18:40:43 +0100 Roger Pau Monn=C3=A9=20
<roger.pau@citrix.com> wrote:


>>     remote        refid      st t when poll reach   delay   offset =
jitter
>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> =3D=3D=3D ntp0      193.67.79.202    2 u  931 1024  377    0.232  =
-4977.5
>> 4207.29 ntp1       66.228.38.73    3 u  890 1024  377    0.267  -4988.5
>> 4616.94 ntp2      64.246.132.14    2 u  990 1024  377    0.324  -4978.0
>> 4207.98 "
>
> I'm sorry, but I have no idea about ntpd, what does the above mean? The
> offset is too big with other peers and ntpd simply disconnects?

Sorry for being so vague (I half hoped someone must have run into this=20
before and posted a "Yes, we noticed the same - this fixes it" reply :)

The above seems to show that time moved forward on the VM by a few seconds. =

This doesn't always happen - I just moved another VM and that shows 'offset =

=3D 8000'. Yet another VM moved at the same time is fine.

Comparing the output of 'date' for that offset 8000 VM with a known 'good'=20
clock - it shows the VM is indeed 8 seconds in the future after the move.

ntp is fussy - and kind of understandably decides that's too much time=20
difference to slowly ebb away - so just gives up and leaves the VM clock=20
'as is'.

The XenServer the VM was residing on (and the new one it's resident on)=20
both on their server consoles show the correct time (i.e. neither are 8=20
seconds 'ahead') - so it looks like the move somehow gained us 8 seconds=20
(or 5 seconds in the original example).

> There were some issues that I fixed some time ago regarding migration
> and PVHVM guests:
>
> =
http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommit;h=3Df8e8fd56bd7d5675e8=
331
> b4ec74bae76c9dbf24e
> =
http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommit;h=3D32c864a35ece2c24a3=
36d
> 183869a546798a4b241
>
> You should make sure XenServer has both of this commits.

I'll have a look at those - we might be a bit stuck for implementing them=20
if they're XenServer changes, as we run the XenServer ISO's (6.5 SP1=20
w/hotfixes).

-Karl




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84EFB0608568EE976A48039C>