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

[Jim Fehlig]

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