Bug 2052405

Summary: Wrong error info reported when executing virsh client without starting daemon
Product: Red Hat Enterprise Linux 9 Reporter: yafu <yafu>
Component: libvirtAssignee: Virtualization Maintenance <virt-maint>
libvirt sub component: General QA Contact: yafu <yafu>
Status: CLOSED MIGRATED Docs Contact:
Severity: low    
Priority: low CC: fjin, hhan, jsuchane, lizhu, virt-maint, xuzhang, yanqzhan
Version: 9.0Keywords: MigratedToJIRA, Regression, Triaged
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-06-30 18:39:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description yafu 2022-02-09 08:19:52 UTC 
Description of problem:
Wrong error info reported when executing 'virsh list' without starting virtqemud 

Version-Release number of selected component (if applicable):
libvirt-8.0.0-3.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Install libvirt pkgs:
# yum -y install libvirt*

2.Executing virsh list without starting virtqemud:
#virsh list
error: failed to connect to the hypervisor
error: Operation not supported: Cannot use direct socket mode if no URI is set

3.

Actual results:


Expected results:
Should report error to remind no existing socket file, such as:
error: failed to connect to the hypervisor
error: Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory

Additional info:
Comment 1 yafu 2022-02-22 01:59:42 UTC 
Also meet below error info when no virtqemud.sock existing:
# virsh list
error: failed to connect to the hypervisor
error: internal error: connection not open
Comment 2 Han Han 2023-03-31 06:52:09 UTC 
Bisection shows the error msg is updated since v7.4.0-215-g3e9b561139
commit 3e9b561139
Author: Daniel P. Berrangé <berrange>
Date:   Tue May 25 10:45:06 2021 +0100

    remote: add support for probing drivers with modular daemons
    
    With the traditional libvirtd, the virConnectOpen call will probe active
    drivers server side to find which one to use when the URI is NULL/empty.
    
    With the modular daemons though, the remote client does not know which
    daemon to connect in the first place, so we can't rely on virConnectOpen
    probing. Currently the virtproxyd daemon has code to probe for a
    possible driver by looking at which sockets are listening or which
    binaries are installed. The remote client can thus connect to virtproxyd
    which in turn can connect to a real hypervisor driver.
    
    The virtproxyd probing code though isn't something that needs to live in
    virtproxyd. By moving it into the remote client we can get probing
    client side in all scenarios and avoid the extra trip via virtproxyd in
    the common case.
    
    Tested-by: Jim Fehlig <jfehlig>
    Reviewed-by: Michal Privoznik <mprivozn>
    Signed-off-by: Daniel P. Berrangé <berrange>