Bug 1215998 - virsh only works as root
Summary: virsh only works as root
Status: NEW
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Virtualization:Tools (show other bugs)
Version: Leap 15.5
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: James Fehlig
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-06 10:37 UTC by Michal Suchanek
Modified: 2023-10-13 06:19 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Suchanek 2023-10-06 10:37:38 UTC
Running virt-manager in user shell gives window with machines listed, so does 'virsh list --all' as root but as user the virsh command gives no results.
Comment 1 James Fehlig 2023-10-10 15:27:15 UTC
Running virsh as a normal user connects to a session daemon. Do none of the virsh commands work when run as a normal user? E.g. 'virsh version'? For more info about system vs session daemons see

https://libvirt.org/daemons.html#operating-modes
https://wiki.libvirt.org/FAQ.html#what-is-the-difference-between-qemu-system-and-qemu-session-which-one-should-i-use
Comment 2 Michal Suchanek 2023-10-10 15:57:36 UTC
$ virsh 
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # version
Compiled against library: libvirt 9.0.0
Using library: libvirt 9.0.0
Using API: QEMU 9.0.0
Running hypervisor: QEMU 7.1.0

virsh # list --all
 Id   Name   State
--------------------



# virsh
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # version
Compiled against library: libvirt 9.0.0
Using library: libvirt 9.0.0
Using API: QEMU 9.0.0
Running hypervisor: QEMU 7.1.0

virsh # list --all
 Id   Name        State
----------------------------
 9    master      running
 10   minion1     running
 -    sles12sp5   shut off

Ultimately I do not want to use a session deamon, I want to manage the system daemon - the virt-manager can do it, virsh cannot.
Comment 3 Michal Suchanek 2023-10-10 16:03:10 UTC
So it's different defaults between different tools using the same infrastructure.

$ virsh -c qemu:///system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # list --all
 Id   Name        State
----------------------------
 9    master      running
 10   minion1     running
 -    sles12sp5   shut off

I don't see any way to preset the -c option in some sort of configuration in vrsh, either. virt-manager does have some connection configuration for this.
Comment 4 James Fehlig 2023-10-10 16:12:26 UTC
(In reply to Michal Suchanek from comment #3)
> I don't see any way to preset the -c option in some sort of configuration in
> vrsh, either. virt-manager does have some connection configuration for this.

https://libvirt.org/uri.html#default-uri-choice
Comment 5 Michal Suchanek 2023-10-10 16:55:21 UTC
(In reply to James Fehlig from comment #4)
> (In reply to Michal Suchanek from comment #3)
> > I don't see any way to preset the -c option in some sort of configuration in
> > vrsh, either. virt-manager does have some connection configuration for this.
> 
> https://libvirt.org/uri.html#default-uri-choice

 If the URI passed to virConnectOpen* is NULL or empty string, then libvirt will use the following logic to determine what URI to use.

 The environment variable LIBVIRT_DEFAULT_URI

 The client configuration file uri_default parameter

 Probe each hypervisor in turn until one that works is found

That only confirms that there is no way to specify the URI other than an environment variable, yet the virt-manager and virsh default to different URI.

Interestingly, it tells about 'client configuration file' but does not say what it is. The only description I see is here: https://libvirt.org/auth.html and that only talks about per-connection section with credentials - which section to use still has to be selected.
Comment 6 James Fehlig 2023-10-10 17:14:41 UTC
(In reply to Michal Suchanek from comment #5)
> Interestingly, it tells about 'client configuration file' but does not say
> what it is. The only description I see is here:
> https://libvirt.org/auth.html and that only talks about per-connection
> section with credentials - which section to use still has to be selected.

The client config file is described here

https://libvirt.org/uri.html#configuring-uri-aliases

At this point, I'm not sure what the bug is here. Can you please re-clarify that for me? :-)
Comment 7 Michal Suchanek 2023-10-10 17:19:55 UTC
(In reply to James Fehlig from comment #6)
> (In reply to Michal Suchanek from comment #5)
> > Interestingly, it tells about 'client configuration file' but does not say
> > what it is. The only description I see is here:
> > https://libvirt.org/auth.html and that only talks about per-connection
> > section with credentials - which section to use still has to be selected.
> 
> The client config file is described here
> 
> https://libvirt.org/uri.html#configuring-uri-aliases

That's an alias, not the default.

> 
> At this point, I'm not sure what the bug is here. Can you please re-clarify
> that for me? :-)

Run virt-manager, install a machine, run virsh, no machine present.
Comment 8 James Fehlig 2023-10-10 17:37:19 UTC
(In reply to Michal Suchanek from comment #7)
> That's an alias, not the default.

You asked about the client config file, which is described in that section.

"The configuration file is /etc/libvirt/libvirt.conf for the root user, or $XDG_CONFIG_HOME/libvirt/libvirt.conf for any unprivileged user"

In there you can put

uri_default='qemu:///system'

> > At this point, I'm not sure what the bug is here. Can you please re-clarify
> > that for me? :-)
> 
> Run virt-manager, install a machine, run virsh, no machine present.

If started as a normal user, IMO virt-manager should connect to the session daemon by default. Something for Charles to consider.
Comment 9 Michal Suchanek 2023-10-10 17:47:36 UTC
(In reply to James Fehlig from comment #8)
> (In reply to Michal Suchanek from comment #7)
> > That's an alias, not the default.
> 
> You asked about the client config file, which is described in that section.
> 
> "The configuration file is /etc/libvirt/libvirt.conf for the root user, or
> $XDG_CONFIG_HOME/libvirt/libvirt.conf for any unprivileged user"
> 
> In there you can put
> 
> uri_default='qemu:///system'

Where exactly? In what format?

The full format of the file is not described.

> > > At this point, I'm not sure what the bug is here. Can you please re-clarify
> > > that for me? :-)
> > 
> > Run virt-manager, install a machine, run virsh, no machine present.
> 
> If started as a normal user, IMO virt-manager should connect to the session
> daemon by default. Something for Charles to consider.

IMO virsh should default to the system daemon by default. There aren't particularly useful VM configurations available from the session daemon AFAIK. Anyway, whatever the default at least it should be the same for both.
Comment 10 James Fehlig 2023-10-10 19:57:20 UTC
(In reply to Michal Suchanek from comment #9)
> (In reply to James Fehlig from comment #8)
> > (In reply to Michal Suchanek from comment #7)
> > > That's an alias, not the default.
> > 
> > You asked about the client config file, which is described in that section.
> > 
> > "The configuration file is /etc/libvirt/libvirt.conf for the root user, or
> > $XDG_CONFIG_HOME/libvirt/libvirt.conf for any unprivileged user"
> > 
> > In there you can put
> > 
> > uri_default='qemu:///system'
> 
> Where exactly? In what format?

/etc/libvirt/libvirt.conf for root, $XDG_CONFIG_HOME/libvirt/libvirt.conf for regular user. The format is simple key/value pairs, like a flat ini I suppose. IMO /etc/libvirt/libvirt.conf is self documenting. Copy it to $XDG_CONFIG_HOME/libvirt/libvirt.conf and uncomment the uri_default entry.

> IMO virsh should default to the system daemon by default. 

That would be quite the behavior change that would make for some unhappy users. Sorry, but I won't be making such a change to libvirt :-).

I'd have to check the behavior of virt-manager on a fresh install. I thought you had to explicitly add a connection when running virt-manager the first time, in which case the connection should default to the session daemon when invoked as a regular user and simply accepting the defaults.
Comment 11 Michal Suchanek 2023-10-13 06:19:07 UTC
(In reply to James Fehlig from comment #10)
> (In reply to Michal Suchanek from comment #9)
> > (In reply to James Fehlig from comment #8)
> > > (In reply to Michal Suchanek from comment #7)
> > > > That's an alias, not the default.
> > > 
> > > You asked about the client config file, which is described in that section.
> > > 
> > > "The configuration file is /etc/libvirt/libvirt.conf for the root user, or
> > > $XDG_CONFIG_HOME/libvirt/libvirt.conf for any unprivileged user"
> > > 
> > > In there you can put
> > > 
> > > uri_default='qemu:///system'
> > 
> > Where exactly? In what format?
> 
> /etc/libvirt/libvirt.conf for root, $XDG_CONFIG_HOME/libvirt/libvirt.conf
> for regular user. The format is simple key/value pairs, like a flat ini I

No, ini files have all values in sections, and this file does not have sections. They do not require quoting values but this one does. No documentation on the format I can see anywhere.

> suppose. IMO /etc/libvirt/libvirt.conf is self documenting. 

Which  is not linked from the documentation, either.

> Copy it to
> $XDG_CONFIG_HOME/libvirt/libvirt.conf and uncomment the uri_default entry.
> 
> > IMO virsh should default to the system daemon by default. 
> 
> That would be quite the behavior change that would make for some unhappy
> users. Sorry, but I won't be making such a change to libvirt :-).

Each tool managing different VM pool also makes for unhappy users. 

> I'd have to check the behavior of virt-manager on a fresh install. I thought
> you had to explicitly add a connection when running virt-manager the first
> time, in which case the connection should default to the session daemon when
> invoked as a regular user and simply accepting the defaults.

This is a fresh install and I get the system VM connection with virt-manager.

I don't know what use case do you have in mind with the session pool. Having one VM pool that can be managed with different tools as needed sounds much more useful. Users that do not have access to the default system pool and have use case for non-system pools can explicitly select them but I don't see much use for the session pool as a default.