On Fri, Sep 19, 2014 at 02:37:12PM -0600, Jim Fehlig wrote:
Michal Privoznik wrote:On 08.09.2014 18:30, Jim Fehlig wrote:If an NTP server is configured on the host, it is possible for libvirt-guests to start before the NTP service, in which case guest clocks won't be synchronized to the host clock. Add ntp-wait.service to "After" in libvirt-guests systemd service file, ensuring NTP has synchronized the host clock before starting any guests. Signed-off-by: Jim Fehlig <jfehlig suse com> --- tools/libvirt-guests.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libvirt-guests.service.in b/tools/libvirt-guests.service.in index d8d7adf..226b3bd 100644 --- a/tools/libvirt-guests.service.in +++ b/tools/libvirt-guests.service.in @@ -1,6 +1,6 @@ [Unit] Description=Suspend Active Libvirt Guests -After=network.target libvirtd.service +After=network.target libvirtd.service ntp-wait.service Documentation=man:libvirtd(8) Documentation=http://libvirt.orgWell, guest can have their own ntp-client (and in most cases they do, right?).I think most do, but know of at least two users who want to use kvmclock with no ntp in the guests :).
I'm sure there are way more users without ntp clients inside their guests. I'm just wondering what's the difference when libvirt-guests starts before or after ntp has synchronized their clocks. Is it that they have the time reset to a little bit inaccurate time? Or are they off way too much?
I mean, since guests can be paused, saved & restored back, their time is often off. So the best is to have an ntp-client running inside the guest.
Yes, but if it's way off, ntp will refuse to update the time; that's why we are resetting the time, isn't it?
Yep. I mentioned this, but seems they don't use save, restore, migrate, et. al., since it wasn't a concern. But I'm fine handling this downstream. Thanks!
Well, if they use libvirt-guests, they use at least save/restore :) Unfortunately I'm not very familiar with systemd files, but my guess is that After=ntp-wait.service means it should be started after the time is synchronized if and only if the ntp-wait.service unit is enabled, otherwise it doesn't require it. My point is that if this doesn't enable ntp synchronization for users that don't want it, then we should probably push his upstream. There is slight added benefit and no drawbacks. Martin
Description: Digital signature