Bug 627693 - virsh doesn't give correct error when run as non-root
virsh doesn't give correct error when run as non-root
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-08-26 13:12 EDT by Bill Nottingham
Modified: 2014-03-16 23:24 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-31 07:00:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2010-08-26 13:12:40 EDT
Description of problem:

[notting@nostromo: ~]$ virsh edit splat-f13
error: failed to get domain 'splat-f13'
error: Domain not found: no domain with matching name 'splat-f13'

[notting@nostromo: ~]$ su
[root@nostromo notting]# virsh edit splat-f13

Ideally, I'd get an error message from the unprivleged execution that more accurately describes what happened.

Version-Release number of selected component (if applicable):

Comment 1 Daniel Berrange 2010-08-31 07:00:29 EDT
The error message *does* accurate describe what happened, thus...

 * No URI was provided to virsh, so it picked the first one it finds.
    - When running unprivileged it picks 'qemu:///session' which is a private per-user instance of libvirtd. 
    - When running privileged, it picks 'qemu:///system' which is a single system wide instance of libvirtd.
   (It might not even pick QEMU at all if QEMU is not installed, trying lxc or xen or something else)

 * The session & system instances of libvirt are completely separate, having no knowledge of each other's guests. Thus the message "no domain with matching name 'splat-f13'" is correct.

Note You need to log in before you can comment on or make changes to this bug.