[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] libvirt-guests: wait for ntp service

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
index d8d7adf..226b3bd 100644
--- a/tools/libvirt-guests.service.in
+++ b/tools/libvirt-guests.service.in
@@ -1,6 +1,6 @@
  Description=Suspend Active Libvirt Guests
-After=network.target libvirtd.service
+After=network.target libvirtd.service ntp-wait.service

Well, guest can have their own ntp-client (and in most cases they do,

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

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.


Attachment: signature.asc
Description: Digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]