'Live' Migrate messes up NTP on FreeBSD domU - any suggestions?

[Karl Pielorz]

--On 3 November 2015 at 12:21:20 +0100 Roger Pau Monné 
<roger.pau at citrix.com> wrote:

> Can't you tell ntpd to just resynchronize no matter what skew it detects?

Probably - I'll have to do some digging - I had hoped someone had hit this 
already, though I'm also a little concerned about throwing a 7 second 'back 
in time' jump on the system.

>> Are either of those fixes likely to cure this?
>
> Hm, I don't think so. Both commits are present from 4.3 onwards, and
> IIRC XenServer 6.5 is based on Xen 4.4, which should contain both fixes.
>
> Is XenServer also synchronized using ntpd? When a guest resumes from
> migration is updates it's current time based on the time provided by the
> hypervisor, so if the hosts themselves are not synchronized you could
> see skews like that.

All the clocks on the XenServers are NTP sync'd - and are in sync 
(confirmed from the consoles).

When the domU moves - it's clock moves >ahead< in time of both the server 
it's leaving, and the server it's moved to.

I re-ran the test adding checks for the source (Xen1) and destination 
(Xen2) XenServer clocks - and I get:

  Me: Tue Nov  3 18:56:29 GMT 2015
Them: Tue Nov  3 18:56:29 GMT 2015
Xen1: Tue Nov  3 18:56:29 GMT 2015
Xen2: Tue Nov  3 18:56:29 GMT 2015

(All in sync)

[moving FreeBSD from Xen1 to Xen2]

  Me: Tue Nov  3 18:56:39 GMT 2015
(Gained 4 seconds)
Them: Tue Nov  3 18:56:35 GMT 2015
Xen1: Tue Nov  3 18:56:35 GMT 2015
Xen2: Tue Nov  3 18:56:35 GMT 2015

  Me: Tue Nov  3 18:56:43 GMT 2015
(Completed - gained 7 seconds total)
Them: Tue Nov  3 18:56:36 GMT 2015
Xen1: Tue Nov  3 18:56:36 GMT 2015
Xen2: Tue Nov  3 18:56:36 GMT 2015

  Me: Tue Nov  3 18:56:44 GMT 2015
Them: Tue Nov  3 18:56:37 GMT 2015
Xen1: Tue Nov  3 18:56:37 GMT 2015
Xen2: Tue Nov  3 18:56:37 GMT 2015

So you can see it's now 7 seconds ahead of both 'Them' (external bare metal 
machine running ntp) and Xen1/Xen2.

I re-ran the test without ntp loaded on the domU - and the same thing 
happens - so it's not ntp causing it.

We've kind of 'lived with it' until now - but as the quantity of VM's 
increases - it becomes more of a pain :(

-Karl