Re: [PATCH 0/2] libvirt-guests: small improvments

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

 



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





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux