Mailing List Archive

Q: NTP Problem after Xen live migration
Hello!

I managed to migrate my Xen virtual machines live from one node to another. Soe of the VMs have several GB of RAM with databases, so live migration takes a while. However the typical user does not notice that the node migrated (network connections stay alive). Unfortunately NTP seems to notice the time migration took (77s in this case):

ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 3 64 377 0.000 0.000 0.001
132.199.176.18 192.53.103.108 2 u 180 512 377 0.239 -77753. 41560.8
132.199.176.153 192.53.103.104 2 u 185 512 377 0.275 -77751. 41560.1
172.20.16.1 132.199.176.153 3 u 191 512 377 0.378 -77753. 41560.5
172.20.16.5 132.199.176.18 3 u 251 512 377 0.107 -77754. 41560.2

So it thinks the other nodes are off by 77.7 seconds and sync to ist own clock.

Other VMs show simular results:
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 6 64 377 0.000 0.000 0.001
132.199.176.18 192.53.103.108 2 u 582 1024 377 0.242 -78361. 78359.9
132.199.176.153 192.53.103.104 2 u 546 1024 377 0.521 -78360. 78360.1

# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 64 64 377 0.000 0.000 0.001
132.199.176.18 192.53.103.108 2 u 653 1024 377 0.326 -77837. 77836.7
132.199.176.153 192.53.103.104 2 u 969 1024 377 0.453 -77835. 77835.8
172.20.16.1 132.199.176.153 3 u 971 1024 377 4.937 -77837. 77834.5
172.20.16.5 132.199.176.153 3 u 966 1024 377 6.283 -3.295 77836.9

As it turn out, the time in the VMs is actually wrong after migration:
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 51 64 377 0.000 0.000 0.001
+132.199.176.18 192.53.103.108 2 u 71 1024 377 0.362 -77840. 2.573
+132.199.176.153 192.53.103.104 2 u 386 1024 377 0.506 -77838. 2.834
*172.20.16.1 132.199.176.153 3 u 391 1024 377 4.140 -77840. 2.744
+172.20.16.5 132.199.176.18 3 u 386 1024 377 3.767 -77841. 1.409

If I want to continue to use NTP, what are the recommendations?

Regards,
Ulrich


_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
Re: Q: NTP Problem after Xen live migration [ In reply to ]
On 2014-04-16T09:18:21, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:

> As it turn out, the time in the VMs is actually wrong after migration:
> # ntpq -pn
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> 127.127.1.0 .LOCL. 10 l 51 64 377 0.000 0.000 0.001
> +132.199.176.18 192.53.103.108 2 u 71 1024 377 0.362 -77840. 2.573
> +132.199.176.153 192.53.103.104 2 u 386 1024 377 0.506 -77838. 2.834
> *172.20.16.1 132.199.176.153 3 u 391 1024 377 4.140 -77840. 2.744
> +172.20.16.5 132.199.176.18 3 u 386 1024 377 3.767 -77841. 1.409
>
> If I want to continue to use NTP, what are the recommendations?

Probably a kernel or hypervisor bug. If these are SLES systems, please
report (with full versions etc) to NTS, but has little to do with HA.


Regards,
Lars

--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems