Date: Tue, 10 Nov 2015 09:38:56 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 204424] When live migrating FreeBSD domU's under XenServer the domU moves it's clock several seconds into the future. Message-ID: <bug-204424-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204424 Bug ID: 204424 Summary: When live migrating FreeBSD domU's under XenServer the domU moves it's clock several seconds into the future. Product: Base System Version: 10.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: kpielorz@tdx.co.uk When 'live migrating' FreeBSD domU 'guests' under XenServer - the FreeBSD box will 'gain' around 5-8 seconds of time, into the future. This is enough (mostly) to stop NTP from trying to 'drag the host' back into sync (where NTP is used). It also enough to upset anything remotely time critical on the system (and obviously record bad times in syslog and other apps) - for what is usually a time-sync'd system. Even worse is when you have to 'drag' the clock back in time by several seconds (e.g. by running 'ntpdate'). If NTP is not used - the domU / 'guest' sits ahead of time by this amount permanently. To test - I setup a FreeBSD guest/domU under XenServer 6.5 (SP1 + hotfixes), with 'xe-guest-utilities' pkg installed (to make it 'agile'). I then wrote a script that displays side by side, the domU's clock - the Xen Server the VM is running on (Xen1), the Xen Server the VM is moving to (Xen2) - and the clock from an external (bare metal) host [that was NTP sync'd] - you can then see when performing the live migrate that the clock 'picks up time' and ends up seconds ahead of everything else: " domU: Tue Nov 3 18:56:29 GMT 2015 External: 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 domU: Tue Nov 3 18:56:30 GMT 2015 External: Tue Nov 3 18:56:30 GMT 2015 Xen1: Tue Nov 3 18:56:30 GMT 2015 Xen2: Tue Nov 3 18:56:30 GMT 2015 (All in sync) [After starting to move FreeBSD from Xen1 to Xen2] domU: Tue Nov 3 18:56:39 GMT 2015 (Gained 4 seconds) External: 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 domU: Tue Nov 3 18:56:43 GMT 2015 (Completed - gained 7 seconds total) External: 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 domU: Tue Nov 3 18:56:44 GMT 2015 External: 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 " To reproduce: - Install two v6.5 XenServers (from the ISO available at www.xenserver.org) - on ours we have SP1 + all hotfixes installed (though the problem exists without these as well) - and create a 2 XenServer 'pool' from them. We use shared iSCSI storage - but the issue also occurs with XenServer local storage - so likely not storage related. - Create a FreeBSD domU (Guest) from the 10.1 or 10.2 install ISO's - and install 'xe-guest-utilities' to make it agile. - Live migrate the domU from one XenServer to the other. Pretty much all the time the domU will gain from 5-8 seconds (6 seems to be prevalent as the seconds gained). We have reproduced this on two XenServer pools - once is four server HP Proliant DL series (Gen 8) based pool - using Xeon E3-1220 v3. The other is an older two Server SuperMicro (X8DTL-IF) based pool based on Xeon L5630. All systems have latest BIOSes installed from HP / SuperMicro. This issue makes maintenance a -real- pain - as mass evacuation of a XenServer (e.g. for patching) causes all the FreeBSD domU's pushed from it to need their clocks fixing up again (and again, when they are moved back). -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-204424-8>