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
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
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