On 21.02.2014 13:50, Daniel P. Berrange wrote:
On Fri, Feb 21, 2014 at 01:32:36PM +0100, Michal Privoznik wrote:
I've noticed that in some cases systemd was quick enough and even
if libvirt-guests.service is marked to be started after the
libvirtd.service my guests were not resumed as
libvirt-guests.sh failed to connect. This is because of a
simple fact: systemd correctly starts libvirt-guests after it
execs libvirtd. However, the daemon is not able to accept
connections right from the start. It's doing some
initialization which may take ages. This problem is not limited
to systemd only, indeed. Any init system that is able to startup
services in parallel (e.g. OpenRC) may run into this situation.
The fix is to try connecting not only once, but continuously a few
times with a small sleep in between tries.
The long term fix for this will be to use socket activation for
libvirtd. Unfortunately we can't do that yet since then VMs marked
to autostart on boot won't be booted
I think that we can create a .socket within libvirt and set
libvirt-guests.service to be dependent on the libvirt.socket. Something
among:
diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in
index e1f2a07..35963ce 100644
--- a/daemon/libvirtd.service.in
+++ b/daemon/libvirtd.service.in
@@ -22,5 +22,9 @@ Restart=on-failure
# Override the maximum number of opened files
#LimitNOFILE=2048
+[Socket]
+ListenStream=/var/run/libvirt/libvirt-sock
+ListenStream=0.0.0.0:16509
+
[Install]
WantedBy=multi-user.target
diff --git a/tools/libvirt-guests.service.in
b/tools/libvirt-guests.service.in
index d8d7adf..03120da 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.socket
Documentation=man:libvirtd(8)
Documentation=http://libvirt.org
My inspiration comes from here:
https://bugzilla.redhat.com/show_bug.cgi?id=714426
However, I was unable to make this work with this particular change.
Moreover, it would require users to adjust libvirtd.service file if they
ever change socket path or listen address. That's why I've decided for
approach implemented in 3/3.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list