[Bug 204424] When live migrating FreeBSD domU's under XenServer the domU moves it's clock several seconds into the future.
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Tue Nov 10 09:38:56 UTC 2015
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
Severity: Affects Only Me
Assignee: freebsd-bugs at FreeBSD.org
Reporter: kpielorz at 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
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
- 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
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
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.
More information about the freebsd-bugs