[libvirt] [PATCH] libvirt-guests: wait for ntp service
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.org -- 1.8.4.5
Any comments on this change? Regards, Jim 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.org
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.org
Well, guest can have their own ntp-client (and in most cases they do, right?). 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. Michal
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.org
Well, 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 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.
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! Regards, Jim
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.org
Well, 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
Martin Kletzander wrote:
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.org
Well, 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?
They are off by the ntp adjustment. As I understand it, the guests start and read the host clock, which is later adjusted by ntp.
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 :)
They have ON_SHUTDOWN=shutdown.
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.
Yes, this is my understanding too. Regards, Jim
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
On 20.09.2014 01:36, Jim Fehlig wrote:
Martin Kletzander wrote:
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.org
Well, 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?
They are off by the ntp adjustment. As I understand it, the guests start and read the host clock, which is later adjusted by ntp.
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 :)
They have ON_SHUTDOWN=shutdown.
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.
Yes, this is my understanding too.
And so is mine. The only concern I have is that syncing time on cold boot of the host may take ages. But on the other hand, it's better to start domains later and with correct time than start asap with inaccurate time. ACK then, Michal
On Sat, Sep 20, 2014 at 10:09:40AM +0200, Michal Privoznik wrote:
On 20.09.2014 01:36, Jim Fehlig wrote:
Martin Kletzander wrote:
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.org
Well, 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?
They are off by the ntp adjustment. As I understand it, the guests start and read the host clock, which is later adjusted by ntp.
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 :)
They have ON_SHUTDOWN=shutdown.
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.
Yes, this is my understanding too.
And so is mine. The only concern I have is that syncing time on cold boot of the host may take ages. But on the other hand, it's better to start domains later and with correct time than start asap with inaccurate time. ACK then,
Maybe we could use After=ntpdate.service instead of ntp-wait.service; although starting an ntpdate.service should result in the ntp-wait.service to be automatically active, but this is just my guess, I have no idea how /usr/sbin/ntp-wait works. Wither way, ACK from me too, Martin
Michal Privoznik wrote:
On 20.09.2014 01:36, Jim Fehlig wrote:
Martin Kletzander wrote:
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.org
Well, 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?
They are off by the ntp adjustment. As I understand it, the guests start and read the host clock, which is later adjusted by ntp.
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 :)
They have ON_SHUTDOWN=shutdown.
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.
Yes, this is my understanding too.
And so is mine. The only concern I have is that syncing time on cold boot of the host may take ages.
Yep, I have this concern too. So I dug a bit further and see that ntp-wait (a perl script) scrapes the output of `ntpq -c "rv 0`, waiting for leap_alarm to change to leap_none, leap_add_sec, or leap_del_sec. On my test system, this took ~16min on cold boot :-(. ntp-wait.service failed in the meantime, since it by default calls /usr/sbin/ntp-wait with options to only wait 10min.
But on the other hand, it's better to start domains later and with correct time than start asap with inaccurate time. ACK then,
Given the above observations, I'll wait to see if you change your mind. Regards, Jim
On Mon, Sep 22, 2014 at 04:50:33PM -0600, Jim Fehlig wrote:
Michal Privoznik wrote:
On 20.09.2014 01:36, Jim Fehlig wrote:
Martin Kletzander wrote:
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.
Yes, this is my understanding too.
And so is mine. The only concern I have is that syncing time on cold boot of the host may take ages.
Yep, I have this concern too. So I dug a bit further and see that ntp-wait (a perl script) scrapes the output of `ntpq -c "rv 0`, waiting for leap_alarm to change to leap_none, leap_add_sec, or leap_del_sec. On my test system, this took ~16min on cold boot :-(. ntp-wait.service failed in the meantime, since it by default calls /usr/sbin/ntp-wait with options to only wait 10min.
But on the other hand, it's better to start domains later and with correct time than start asap with inaccurate time. ACK then,
Given the above observations, I'll wait to see if you change your mind.
What would you say to changing it to After=ntpdate.service? That way it won't wait until the clock is synchronized, but it will be started with proper time if ntpdate.service is set up to start in the default runlevel (or is it target in systemd?). I think that's a compromise that has no negative side-effects. Martin
On 23.09.2014 08:06, Martin Kletzander wrote:
On Mon, Sep 22, 2014 at 04:50:33PM -0600, Jim Fehlig wrote:
Michal Privoznik wrote:
On 20.09.2014 01:36, Jim Fehlig wrote:
Martin Kletzander wrote:
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.
Yes, this is my understanding too.
And so is mine. The only concern I have is that syncing time on cold boot of the host may take ages.
Yep, I have this concern too. So I dug a bit further and see that ntp-wait (a perl script) scrapes the output of `ntpq -c "rv 0`, waiting for leap_alarm to change to leap_none, leap_add_sec, or leap_del_sec. On my test system, this took ~16min on cold boot :-(. ntp-wait.service failed in the meantime, since it by default calls /usr/sbin/ntp-wait with options to only wait 10min.
But on the other hand, it's better to start domains later and with correct time than start asap with inaccurate time. ACK then,
Given the above observations, I'll wait to see if you change your mind.
What would you say to changing it to After=ntpdate.service? That way it won't wait until the clock is synchronized, but it will be started with proper time if ntpdate.service is set up to start in the default runlevel (or is it target in systemd?). I think that's a compromise that has no negative side-effects.
I wonder if we should be this specific or use time-sync.target: time-sync.target Services responsible for synchronizing the system clock from a remote source (such as NTP client implementations) should pull in this target and order themselves before it. All services where correct time is essential should be ordered after this unit, but not pull it in. systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the "$time" facility. http://www.freedesktop.org/software/systemd/man/systemd.special.html#time-sy... So I'd say: After=time-sync.target is what we are looking for. Michal
Michal Privoznik wrote:
On 23.09.2014 08:06, Martin Kletzander wrote:
On Mon, Sep 22, 2014 at 04:50:33PM -0600, Jim Fehlig wrote:
Michal Privoznik wrote:
On 20.09.2014 01:36, Jim Fehlig wrote:
Martin Kletzander wrote:
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.
Yes, this is my understanding too.
And so is mine. The only concern I have is that syncing time on cold boot of the host may take ages.
Yep, I have this concern too. So I dug a bit further and see that ntp-wait (a perl script) scrapes the output of `ntpq -c "rv 0`, waiting for leap_alarm to change to leap_none, leap_add_sec, or leap_del_sec. On my test system, this took ~16min on cold boot :-(. ntp-wait.service failed in the meantime, since it by default calls /usr/sbin/ntp-wait with options to only wait 10min.
But on the other hand, it's better to start domains later and with correct time than start asap with inaccurate time. ACK then,
Given the above observations, I'll wait to see if you change your mind.
What would you say to changing it to After=ntpdate.service? That way it won't wait until the clock is synchronized, but it will be started with proper time if ntpdate.service is set up to start in the default runlevel (or is it target in systemd?). I think that's a compromise that has no negative side-effects.
I wonder if we should be this specific or use time-sync.target:
time-sync.target
Services responsible for synchronizing the system clock from a remote source (such as NTP client implementations) should pull in this target and order themselves before it. All services where correct time is essential should be ordered after this unit, but not pull it in. systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the "$time" facility.
http://www.freedesktop.org/software/systemd/man/systemd.special.html#time-sy...
Cool, thanks for finding that!
So I'd say: After=time-sync.target is what we are looking for.
Agreed. I'll send a V2. Regards, Jim
Martin Kletzander wrote:
On Mon, Sep 22, 2014 at 04:50:33PM -0600, Jim Fehlig wrote:
Michal Privoznik wrote:
On 20.09.2014 01:36, Jim Fehlig wrote:
Martin Kletzander wrote:
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.
Yes, this is my understanding too.
And so is mine. The only concern I have is that syncing time on cold boot of the host may take ages.
Yep, I have this concern too. So I dug a bit further and see that ntp-wait (a perl script) scrapes the output of `ntpq -c "rv 0`, waiting for leap_alarm to change to leap_none, leap_add_sec, or leap_del_sec. On my test system, this took ~16min on cold boot :-(. ntp-wait.service failed in the meantime, since it by default calls /usr/sbin/ntp-wait with options to only wait 10min.
But on the other hand, it's better to start domains later and with correct time than start asap with inaccurate time. ACK then,
Given the above observations, I'll wait to see if you change your mind.
What would you say to changing it to After=ntpdate.service?
It appears ntpdate is deprecated https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate Like ifconfig, it is having a very slow death. Regards, Jim
participants (3)
-
Jim Fehlig -
Martin Kletzander -
Michal Privoznik