Bug 627693

Summary: virsh doesn't give correct error when run as non-root
Product: [Fedora] Fedora Reporter: Bill Nottingham <notting>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: aquini, berrange, clalance, crobinso, itamar, jforbes, rvokal, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-31 07:00:29 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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.