On Tue, Jul 12, 2016 at 02:04:12PM +0200, Hoyer-Reuther, Christian wrote:
> Hello list,
> I know this is old but I discovered the same problem and found this thread 
> but no newer information.
> --On Mon Nov 9 10:23:04 UTC 2015 Karl Pielorz <kpielorz_lst at tdx.co.uk> 
> wrote:
> > I've tested this on two pools now. The original production pool (Xeon 
> > E3-1220 v3 @ 3.10GHz) has the issue.
> > 
> > Our office / test pool (Xeon L5630 @ 2.13Ghz) also -has the issue-. Both 
> > are setup pretty much identical (same storage solution, both running 
> > FreeBSD 10.1/10.2-R with 'xe-guest-utilities' installed). Running or not 
> > running NTP doesn't make a difference.
> > 
> > Live migrates result in the domU gaining several seconds (thus breaking NTP 
> > if it is running) else leaving the host 'running in the future' vs. both 
> > external clocks, and NTP sync'd clocks on the xenserver.
> > 
> > As it's easily reproducible I guess I'll file it as a bug...
> We run a XenServer 6.5 SP1 pool with all patches up to XS65ESP1033 on Fujitsu 
> Primergy RX300 S6 servers. My test VM is FreeBSD 10.3 with 
> xe-guest-utilities-6.2.0_2 and xen-guest-tools-4.6.1 installed.
> After live migration the VM's clock is also several seconds in future.


I've done some fixes in HEAD some time ago, that are also present in 11. 
Those have been tested by Karl, and seem to solve the situation (or at least 
the skew is much smaller with those). Sadly migration in both 11 and HEAD 
is currently broken due to other issues, so you cannot test it at the 
moment. Once that's solved I will ping you so that you can test it.

freebsd-xen@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Reply via email to