[PATCH 0/2] libvirt-guests: small improvments
The first patch is trivial. I suppose the second is debatable. If I build libvirt with -Dremote_default_mode=legacy but deploy modular daemons, /run/libvirt/libvirt-sock is provided by virtproxyd, which may or may not be running when libvirt-guests starts/stops. I added an 'After=virtproxyd.socket' ordering dependency to libvirt-guests, but it hasn't fixed an issue I'm seeing when using libvirt-guests+virtproxyd libvirt-guests.sh[2607]: Can't connect to default. Skipping I'm still investigating that issue but think the dependency issue is worth discussing independently. Jim Fehlig (2): libvirt-guests: Remove unused variable 'libvirtd' libvirt-guests: Add systemd odering dependency to virtproxyd tools/libvirt-guests.service.in | 1 + tools/libvirt-guests.sh.in | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) -- 2.41.0
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- tools/libvirt-guests.sh.in | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/libvirt-guests.sh.in b/tools/libvirt-guests.sh.in index 016014215f..344b54390a 100644 --- a/tools/libvirt-guests.sh.in +++ b/tools/libvirt-guests.sh.in @@ -19,7 +19,6 @@ sysconfdir="@sysconfdir@" localstatedir="@localstatedir@" initconfdir="@initconfdir@" -libvirtd="@sbindir@"/libvirtd # Source function library. test ! -r "$sysconfdir"/rc.d/init.d/functions || -- 2.41.0
On Mon, Jul 31, 2023 at 05:06:45PM -0600, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
--- tools/libvirt-guests.sh.in | 1 - 1 file changed, 1 deletion(-)
diff --git a/tools/libvirt-guests.sh.in b/tools/libvirt-guests.sh.in index 016014215f..344b54390a 100644 --- a/tools/libvirt-guests.sh.in +++ b/tools/libvirt-guests.sh.in @@ -19,7 +19,6 @@ sysconfdir="@sysconfdir@" localstatedir="@localstatedir@" initconfdir="@initconfdir@" -libvirtd="@sbindir@"/libvirtd
# Source function library. test ! -r "$sysconfdir"/rc.d/init.d/functions || -- 2.41.0
It's possible to configure a system such that libvirt-guests connects to the legacy /run/libvirt/libvirt-sock when running modular daemons, in which case it connects to virtproxyd. If virtproxyd is stopped before libvirt-guests, the latter will fail to connect and no running guests will be stopped/suspended. Likewise on startup, virtproxyd must be availabel before libvirt-guests. Ensure these conditions are met by adding an 'After=virtproxyd.socket' ordering dependency to libvirt-guests. Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- tools/libvirt-guests.service.in | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/libvirt-guests.service.in b/tools/libvirt-guests.service.in index c547218f2a..29607bbd66 100644 --- a/tools/libvirt-guests.service.in +++ b/tools/libvirt-guests.service.in @@ -9,6 +9,7 @@ After=virtlxcd.socket After=virtvboxd.socket After=virtvzd.socket After=virtxend.socket +After=virtproxyd.socket After=virt-guest-shutdown.target Documentation=man:libvirt-guests(8) Documentation=https://libvirt.org -- 2.41.0
On 8/1/23 01:06, Jim Fehlig wrote:
It's possible to configure a system such that libvirt-guests connects to the legacy /run/libvirt/libvirt-sock when running modular daemons, in which case it connects to virtproxyd. If virtproxyd is stopped before libvirt-guests, the latter will fail to connect and no running guests will be stopped/suspended. Likewise on startup, virtproxyd must be availabel before libvirt-guests. Ensure these conditions are met by
nit: available
adding an 'After=virtproxyd.socket' ordering dependency to libvirt-guests.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
lgtm but don't know enough to add a rb tag. Ciao, C
--- tools/libvirt-guests.service.in | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/libvirt-guests.service.in b/tools/libvirt-guests.service.in index c547218f2a..29607bbd66 100644 --- a/tools/libvirt-guests.service.in +++ b/tools/libvirt-guests.service.in @@ -9,6 +9,7 @@ After=virtlxcd.socket After=virtvboxd.socket After=virtvzd.socket After=virtxend.socket +After=virtproxyd.socket After=virt-guest-shutdown.target Documentation=man:libvirt-guests(8) Documentation=https://libvirt.org
On Mon, Jul 31, 2023 at 05:06:44PM -0600, Jim Fehlig wrote:
The first patch is trivial. I suppose the second is debatable. If I build libvirt with -Dremote_default_mode=legacy but deploy modular daemons, /run/libvirt/libvirt-sock is provided by virtproxyd, which may or may not be running when libvirt-guests starts/stops. I added an 'After=virtproxyd.socket' ordering dependency to libvirt-guests, but it hasn't fixed an issue I'm seeing when using libvirt-guests+virtproxyd
libvirt-guests.sh[2607]: Can't connect to default. Skipping
In this case the connection should use the legacy mode according to the code. I think you are running into the same thing as we were in https://bugzilla.redhat.com/show_bug.cgi?id=1964855 and you want to have virtproxyd.service instead of virtproxyd.socket there. It's complicated, but look at my commit 59d30adacd1d and comment #7 in the above mentioned bugzilla. In any case I think in such a scenario you want the libvirt-guests to connect to the particular daemon. That's the reason I did not modify the virtproxyd in the commit and the reason the socket is not in the service file.
I'm still investigating that issue but think the dependency issue is worth discussing independently.
Jim Fehlig (2): libvirt-guests: Remove unused variable 'libvirtd' libvirt-guests: Add systemd odering dependency to virtproxyd
tools/libvirt-guests.service.in | 1 + tools/libvirt-guests.sh.in | 1 - 2 files changed, 1 insertion(+), 1 deletion(-)
-- 2.41.0
On 8/1/23 08:11, Martin Kletzander wrote:
On Mon, Jul 31, 2023 at 05:06:44PM -0600, Jim Fehlig wrote:
The first patch is trivial. I suppose the second is debatable. If I build libvirt with -Dremote_default_mode=legacy but deploy modular daemons, /run/libvirt/libvirt-sock is provided by virtproxyd, which may or may not be running when libvirt-guests starts/stops. I added an 'After=virtproxyd.socket' ordering dependency to libvirt-guests, but it hasn't fixed an issue I'm seeing when using libvirt-guests+virtproxyd
libvirt-guests.sh[2607]: Can't connect to default. Skipping
In this case the connection should use the legacy mode according to the code.
Nod.
I think you are running into the same thing as we were in
https://bugzilla.redhat.com/show_bug.cgi?id=1964855
and you want to have virtproxyd.service instead of virtproxyd.socket there. It's complicated, but look at my commit 59d30adacd1d and comment #7 in the above mentioned bugzilla.
Yes, I see the same problem. Thanks for the pointer! But unless I have something misconfigured, the suggestions you made to the daemon docs don't work for me. My setup is a recent openSUSE Tumbleweed with systemd 253.7 and libvirt 9.6.0 built with -Dremote_default_mode=direct. The unit section of /etc/systemd/system/libvirt-guests.service contains [Unit] Description=Suspend/Resume Running libvirt Guests Requires=virt-guest-shutdown.target After=network.target After=time-sync.target After=virtqemud.service After=virt-guest-shutdown.target 'systemctl daemon-reload' executed, virtqemud.service and socket are enabled, and the socket is active. With the service also active, 'systemctl stop libvirt-guests.service' works fine. If virtqemud.service is not running, 'systemctl stop libvirt-guests.service' hangs as described in the bug. Killing the hung libvirt-guests.sh allows the stop job to complete and start job for virtqemud.service to begin. So for me it seems the bug still exists when using the default URI.
In any case I think in such a scenario you want the libvirt-guests to connect to the particular daemon. That's the reason I did not modify the virtproxyd in the commit and the reason the socket is not in the service file.
Indeed, if I set 'uri_default = "qemu:///system"' in /etc/libvirt/libvirt.conf, then 'systemctl stop libvirt-guests.service' succeeds even when virtqemud.service is not active. Regards, Jim
On Wed, Aug 02, 2023 at 01:40:16PM -0600, Jim Fehlig wrote:
On 8/1/23 08:11, Martin Kletzander wrote:
On Mon, Jul 31, 2023 at 05:06:44PM -0600, Jim Fehlig wrote:
The first patch is trivial. I suppose the second is debatable. If I build libvirt with -Dremote_default_mode=legacy but deploy modular daemons, /run/libvirt/libvirt-sock is provided by virtproxyd, which may or may not be running when libvirt-guests starts/stops. I added an 'After=virtproxyd.socket' ordering dependency to libvirt-guests, but it hasn't fixed an issue I'm seeing when using libvirt-guests+virtproxyd
libvirt-guests.sh[2607]: Can't connect to default. Skipping
In this case the connection should use the legacy mode according to the code.
Nod.
I think you are running into the same thing as we were in
https://bugzilla.redhat.com/show_bug.cgi?id=1964855
and you want to have virtproxyd.service instead of virtproxyd.socket there. It's complicated, but look at my commit 59d30adacd1d and comment #7 in the above mentioned bugzilla.
Yes, I see the same problem. Thanks for the pointer! But unless I have something misconfigured, the suggestions you made to the daemon docs don't work for me. My setup is a recent openSUSE Tumbleweed with systemd 253.7 and libvirt 9.6.0 built with -Dremote_default_mode=direct. The unit section of /etc/systemd/system/libvirt-guests.service contains
[Unit] Description=Suspend/Resume Running libvirt Guests Requires=virt-guest-shutdown.target After=network.target After=time-sync.target After=virtqemud.service After=virt-guest-shutdown.target
'systemctl daemon-reload' executed, virtqemud.service and socket are enabled, and the socket is active. With the service also active, 'systemctl stop libvirt-guests.service' works fine. If virtqemud.service is not running, 'systemctl stop libvirt-guests.service' hangs as described in the bug. Killing the hung libvirt-guests.sh allows the stop job to complete and start job for virtqemud.service to begin. So for me it seems the bug still exists when using the default URI.
In any case I think in such a scenario you want the libvirt-guests to connect to the particular daemon. That's the reason I did not modify the virtproxyd in the commit and the reason the socket is not in the service file.
Indeed, if I set 'uri_default = "qemu:///system"' in /etc/libvirt/libvirt.conf, then 'systemctl stop libvirt-guests.service' succeeds even when virtqemud.service is not active.
And that is with or without virtproxyd? Can you check the other use case? I don't have the setup on hand. Can you also capture the output of `systemctl list-jobs` during the blockage? Just to see it really is systemd what we're waiting for.
Regards, Jim
On 8/3/23 05:52, Martin Kletzander wrote:
On Wed, Aug 02, 2023 at 01:40:16PM -0600, Jim Fehlig wrote:
On 8/1/23 08:11, Martin Kletzander wrote:
On Mon, Jul 31, 2023 at 05:06:44PM -0600, Jim Fehlig wrote:
The first patch is trivial. I suppose the second is debatable. If I build libvirt with -Dremote_default_mode=legacy but deploy modular daemons, /run/libvirt/libvirt-sock is provided by virtproxyd, which may or may not be running when libvirt-guests starts/stops. I added an 'After=virtproxyd.socket' ordering dependency to libvirt-guests, but it hasn't fixed an issue I'm seeing when using libvirt-guests+virtproxyd
libvirt-guests.sh[2607]: Can't connect to default. Skipping
In this case the connection should use the legacy mode according to the code.
Nod.
I think you are running into the same thing as we were in
https://bugzilla.redhat.com/show_bug.cgi?id=1964855
and you want to have virtproxyd.service instead of virtproxyd.socket there. It's complicated, but look at my commit 59d30adacd1d and comment #7 in the above mentioned bugzilla.
Yes, I see the same problem. Thanks for the pointer! But unless I have something misconfigured, the suggestions you made to the daemon docs don't work for me. My setup is a recent openSUSE Tumbleweed with systemd 253.7 and libvirt 9.6.0 built with -Dremote_default_mode=direct. The unit section of /etc/systemd/system/libvirt-guests.service contains
[Unit] Description=Suspend/Resume Running libvirt Guests Requires=virt-guest-shutdown.target After=network.target After=time-sync.target After=virtqemud.service After=virt-guest-shutdown.target
'systemctl daemon-reload' executed, virtqemud.service and socket are enabled, and the socket is active. With the service also active, 'systemctl stop libvirt-guests.service' works fine. If virtqemud.service is not running, 'systemctl stop libvirt-guests.service' hangs as described in the bug. Killing the hung libvirt-guests.sh allows the stop job to complete and start job for virtqemud.service to begin. So for me it seems the bug still exists when using the default URI.
In any case I think in such a scenario you want the libvirt-guests to connect to the particular daemon. That's the reason I did not modify the virtproxyd in the commit and the reason the socket is not in the service file.
Indeed, if I set 'uri_default = "qemu:///system"' in /etc/libvirt/libvirt.conf, then 'systemctl stop libvirt-guests.service' succeeds even when virtqemud.service is not active.
And that is with or without virtproxyd? Can you check the other use case? I don't have the setup on hand.
Without virtproxyd. I see the same when using virtproxyd and libvirt built with -Dremote_default_mode=legacy.
Can you also capture the output of `systemctl list-jobs` during the blockage? Just to see it really is systemd what we're waiting for.
# systemctl list-jobs JOB UNIT TYPE STATE 1010 virtqemud.service start waiting 1009 libvirt-guests.service stop running Regards, Jim
participants (3)
-
Claudio Fontana -
Jim Fehlig -
Martin Kletzander