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

[Martin Kletzander]

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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20230803/5f7540c1/attachment.sig>