This operative errors are:

Mar 11 14:52:52 rubik libvirtd[11626]: unable to set security context 'system_u:object_r:virt_content_t:s0' on '/mnt/work/VM/RHEL5.8.img': Operation not permitted

But this is expected: you are likely running virt-manager as a regular user. In typical operation we use polkit to get privileged access to libvirt. However there's no way to share that privilege with libguestfs. So libguestfs runs as your regular user, which can't access your root or qemu owned images in /mnt

So you can run virt-manager as root, or give your user access to those disk images with setfacl or similar, but there isn't anything virt-manager can do to make it 'just work'.

If I missed something, please reopen

I am running virt-manager as a regular user, yes.

I have read access to the images though:

$ ls -l /mnt/work/VM/RHEL5.8.img 
-rw-rw-r--. 1 root root 7340032000 Aug  7  2013 /mnt/work/VM/RHEL5.8.img

Running this as a regular user works:
LIBGUESTFS_BACKEND=direct virt-inspector -a /mnt/work/VM/RHEL5.8.img

(In reply to Cole Robinson from comment #1)
> This operative errors are:
> 
> Mar 11 14:52:52 rubik libvirtd[11626]: unable to set security context
> 'system_u:object_r:virt_content_t:s0' on '/mnt/work/VM/RHEL5.8.img':
> Operation not permitted
> 
> But this is expected: you are likely running virt-manager as a regular user.
> In typical operation we use polkit to get privileged access to libvirt.
> However there's no way to share that privilege with libguestfs. So
> libguestfs runs as your regular user, which can't access your root or qemu
> owned images in /mnt

I don't think it was fair to close this, since doesn't this indicate
a bug in libguestfs (or libvirt)?

We have long talked about passing libvirt connections & domain
objects over to libguestfs.  It's tricky to implement because of
problems with generating the language bindings.

(In reply to Richard W.M. Jones from comment #3)
> (In reply to Cole Robinson from comment #1)
> > This operative errors are:
> > 
> > Mar 11 14:52:52 rubik libvirtd[11626]: unable to set security context
> > 'system_u:object_r:virt_content_t:s0' on '/mnt/work/VM/RHEL5.8.img':
> > Operation not permitted
> > 
> > But this is expected: you are likely running virt-manager as a regular user.
> > In typical operation we use polkit to get privileged access to libvirt.
> > However there's no way to share that privilege with libguestfs. So
> > libguestfs runs as your regular user, which can't access your root or qemu
> > owned images in /mnt
> 
> I don't think it was fair to close this, since doesn't this indicate
> a bug in libguestfs (or libvirt)?
> 
> We have long talked about passing libvirt connections & domain
> objects over to libguestfs.  It's tricky to implement because of
> problems with generating the language bindings.

Yes I was hasty. The proper thing would have been to find an upstream libguestfs RFE and dup to it, or repurpose this bug to track it.

I've filed an RFE for that now: https://bugzilla.redhat.com/show_bug.cgi?id=1075164

But due to Tim's follow up comment, perhaps there's another issue here. But I guess it's expected that the libguestfs libvirt backend needs write access to the disk image parent directory so it can do the svirt magic. So maybe this is just another request for that RFE

(In reply to Cole Robinson from comment #4)
> But due to Tim's follow up comment, perhaps there's another issue here. But
> I guess it's expected that the libguestfs libvirt backend needs write access
> to the disk image parent directory so it can do the svirt magic. So maybe
> this is just another request for that RFE

I guess Dan can answer this, but ...  I wouldn't expect that the
directory should be writable for libguestfs to do inspection.  Certainly
in recent libguestfs, we create an overlay (in a completely different,
temporary directory) and don't touch the original image.  I don't
believe that libvirt looks at backing disks, so it shouldn't touch
the original image either.

(This worked differently with older libguestfs, but Tim is using
Fedora 20 / libguestfs 1.24 so it should work as I described above)

However Tim also said that virt-inspector gave the same error:

 export LIBGUESTFS_BACKEND=libvirt
 virt-inspector -a /mnt/work/VM/F19-1-clone-1.img

The above is a good test since it excludes virt-manager &
polkit from the equation.

ALSO Tim said that this command works:

 export LIBGUESTFS_BACKEND=direct
 virt-inspector -a /mnt/work/VM/F19-1-clone-1.img

This excludes libvirt / sVirt from the equation, but also proves that
the underlying disk image is readable by non-root.

Reporter: Can you verify the statements I make above.

$ virt-inspector -a /mnt/work/VM/RHEL5.9.img 
libguestfs: error: could not create appliance through libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: unable to set security context 'system_u:object_r:virt_content_t:s0' on '/mnt/work/VM/RHEL5.9.img': Operation not permitted [code=38 domain=24]



$ LIBGUESTFS_BACKEND=direct virt-inspector -a /mnt/work/VM/RHEL5.9.img
<?xml version="1.0"?>
<operatingsystems>
  <operatingsystem>
[...]

Same issue found on libguestfs-1.26.1-2.fc20

Sorry - hit save too soon.
Same issue found on libguestfs-1.26.1-2.fc20 trying to mount guestfs image with: 
guestfish -a rhel-guest-image-7.0-20140410.0.x86_64.qcow2 -i ln-sf /dev/null /etc/systemd/system/cloud-init.service
Reproduced the same problem with connection/domains disappearing from virt-manager.

A simple reproducer for the libvirt bug[?] is this:

(1) Create a disk image in a directory.

(2) Ensure the disk image and directory is owned by root, and not
writable by anyone:

$ ll -al notwritable
total 852004
dr-xr-xr-x.  2 root root       4096 May 20 16:11 .
drwxrwxrwt. 58 root root    6963200 May 20 16:15 ..
-r--r--r--.  1 root root 6442450944 May 20 16:12 fedora-20.img

(3) Try running virt-inspector on the disk image *as non-root*:

$ virt-inspector -a ./notwritable/fedora-20.img 
libguestfs: error: could not create appliance through libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: unable to set security context 'system_u:object_r:virt_content_t:s0' on '/tmp/notwritable/fedora-20.img': Operation not permitted [code=38 domain=24]

-----

What is happening here is that *session* libvirtd is trying to set
up an sVirt security context for the appliance, which requires that it
sets labels on everything that the appliance might access.  Because it
is the session libvirtd running as non-root, this is impossible, as the
disk image is owned by root.

If you switch the backend to direct then it works of course because no
sVirt security context is requested so no relabelling is done:

$ LIBGUESTFS_BACKEND=direct virt-inspector -a ./notwritable/fedora-20.img 
<?xml version="1.0"?>
<operatingsystems>
  <operatingsystem>
    <root>/dev/sda3</root>
    <name>linux</name>
[etc]

-----

Fixing bug 1075164 would allow authenticated root libvirt handles to be
passed to libguestfs, which (for virt-manager, the original subject
of this bug) will fix the problem.

I don't see a good way to solve this in libvirt for the session case.

Libvirt could be kinder here, perhaps warning us in advance that setting
up an sVirt context is going to be impossible.  Or libguestfs could
specifically catch this error and retry appliance creation without the
request to set up an sVirt security context.  Or SELinux would not
depend on labelling (controversial ..)

In any case I suspect this is a bug we should document rather than fix,
unless anyone has any other good ideas.

For an update on bug 1075164, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1075164#c9

Although I believe this bug may be covering two slightly
different topics, the original issue which is that virt-manager
want to pass an authenticated libvirt handle to libguestfs
*should* be nearly fixed now.

Cole, shouldn't this bug be assigned to virt-manager?  I see
no reason why the component is libvirt now.

Yeah if the libguestfs and libvirt pieces exist now, we can use this to track virt-manager making use of the new connection sharing.

Created attachment 967654 [details]
/tmp/0001-inspection-Use-add_libvirt_dom-UNTESTED-RHBZ-1075143.patch

The virt-manager patch to fix this should look something like the
attachment.

It will require:
libguestfs >= 1.29.14
libvirt-python >= 1.2.10-2

Both dependencies should be in Rawhide shortly.

Created attachment 977324 [details]
patch

I've done some small changes to the patch, and I think it is ready to go into master.  Richard, I could create the commit under your name if you prefer, or could you send it to the virt-tools mailing list for review?

I went ahead and posted it under your name:

https://www.redhat.com/archives/virt-tools-list/2015-January/msg00028.html

(In reply to Giuseppe Scrivano from comment #14)
> I went ahead and posted it under your name:
> 
> https://www.redhat.com/archives/virt-tools-list/2015-January/msg00028.html

Yup, looks good, thanks.  I was away on holiday until today.