Bug 1095786

Summary:	Could not start storage pool: cannot open volume '/var/lib/libvirt/images/lost+found': Permission denied
Product:	[Community] Virtualization Tools	Reporter:	Richard W.M. Jones <rjones>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	ben.foxmoore, jtomko, rbalakri
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-29 08:41:58 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 Richard W.M. Jones 2014-05-08 14:04:48 UTC

Description of problem:

virt-install insists on creating a storage pool for every
disk path you give it.  This is unhelpful.  However in this
case it doesn't work at all because libvirt is failing:

ERROR    Error: --disk path=/var/lib/libvirt/images/tmp0.img,format=qcow2: Could not start storage pool: cannot open volume '/var/lib/libvirt/images/lost+found': Permission denied

(Note I am running virt-install as non-root)

$ ll -al /var/lib/libvirt/images/
total 4649596
drwxrwxrwx.  4 root   root          4096 May  8 14:40 .
drwxr-xr-x. 13 root   root          4096 Apr 29 22:46 ..
drwxr-xr-x.  2 root   root          4096 Sep  3  2013 dtb-3.9.5-301.fc19.armv7hl
-rw-r--r--.  1 qemu   qemu     180486144 Sep  3  2013 f19arm-1.qcow2
-rw-rw-r--.  1 qemu   qemu    7889485824 Sep  3  2013 Fedora-XFCE-armhfp-19-1-sda.raw
-rw-------.  1 root   root      15909758 Sep  3  2013 initramfs-3.9.5-301.fc19.armv7hl.img
drwx------.  2 root   root         16384 Apr 28 17:09 lost+found
-rw-r--r--.  1 rjones rjones 21478375424 May  8 14:42 tmp0.img
-rw-r--r--.  1 root   root   21474836480 May  4 16:40 tmp-fedora-20.img
-rwxr-xr-x.  1 root   root       4299496 Sep  3  2013 vmlinuz-3.9.5-301.fc19.armv7hl

$ sudo virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       # /var/lib/libvirt/images
 rjones               active     yes       
 tmp                  active     yes       

$ virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       # ~/VirtualMachines


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

libvirt-1.2.2-1.fc21.x86_64
virt-install-1.0.1-3.fc20.noarch

How reproducible:

100%

Steps to Reproduce:
1. Run this as non-root:
  virt-install --print-xml --disk path=/var/lib/libvirt/images/foo

Comment 1 Richard W.M. Jones 2015-03-25 13:49:53 UTC

Another case of the same kind of thing:

$ cd /tmp
$ virt-builder fedora-21
[   1.0] Downloading: http://libguestfs.org/download/builder/fedora-21.xz
[   2.0] Planning how to build this image
[   2.0] Uncompressing
[  13.0] Opening the new disk
[  31.0] Setting a random seed
[  31.0] Setting passwords
virt-builder: Setting random password of root to G82ra3MS0mRrCYT4
[  32.0] Finishing off
                   Output file: fedora-21.img
                   Output size: 4.0G
                 Output format: raw
            Total usable space: 5.2G
                    Free space: 4.5G (86%)

$ virt-install --import --name tmp-test --ram 2048 --disk path=/tmp/fedora-21.img,format=raw --os-variant fedora21
ERROR    Error: --disk path=/tmp/fedora-21.img,format=raw: Could not start storage pool: cannot open volume '/tmp/systemd-private-872f9ad8feec469ea2eec7206961af50-cups.service-fOZPYP': Permission denied

Comment 2 Ján Tomko 2015-07-29 08:41:58 UTC

Fixed by:
commit 56476f6a2d1564c040b749a385c3588a914921f0
Author:     Cole Robinson <crobinso>
AuthorDate: 2015-04-27 11:47:28 -0400
Commit:     Cole Robinson <crobinso>
CommitDate: 2015-04-28 09:42:19 -0400

    storage: fs: Ignore volumes that fail to open with EACCESS/EPERM
    
    Trying to use qemu:///session to create a storage pool pointing at
    /tmp will usually fail with something like:
    
    $ virsh pool-start tmp
    error: Failed to start pool tmp
    error: cannot open volume '/tmp/systemd-private-c38cf0418d7a4734a66a8175996c384f-colord.service-kEyiTA': Permission denied
    
    If any volume in an FS pool can't be opened by the daemon, the refresh
    fails, and the pool can't be used.
    
    This causes pain for virt-install/virt-manager though. Imaging a user
    downloads a disk image to /tmp. virt-manager wants to import /tmp as
    a storage pool, so we can detect what disk format it is, and set the
    XML correctly. However this case will likely fail as explained above.
    
    Change the logic here to skip volumes that fail to open. This could
    conceivably cause user complaints along the lines of 'why doesn't
    libvirt show $ROOT-OWNED-VOLUME-FOO', but figuring that currently
    the pool won't even startup, I don't think there are any current
    users that care about that case.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1103308

git describe: v1.2.15-rc1-13-g56476f6 contains: v1.2.15-rc2~23