Description of problem: I can no longer use /tmp/ to hold the target disk image. This used to work, but I am not sure what the working NVRs are. Version-Release number of selected component (if applicable): virt-install-1.0.1-3.fc20.noarch How reproducible: Every time Steps to Reproduce: 1. virt-install -n temptest -r 2048 --noautoconsole --graphics vnc --disk path=/tmp/diskIPGADE.img,format=raw,size=5 --cdrom ~/isos/Fedora-20-x86_64-netinst.iso Actual results: ERROR Error: --disk path=/tmp/diskIPGADE.img,format=raw,size=5: Could not start storage pool: cannot open volume '/tmp/atop.d': Permission denied If I put the image on /var/tmp it runs fine.
Latest virt-install will always try to create a libvirt storage pool for the disk image parent directory, so we can ask libvirt to do any storage creation or probing and not have to duplicate that logic. However libvirt falls over if it doesn't have permissions for any file in that directory. Most users aren't likely to hit this with /tmp since they use the system libvirtd instance which runs as root, but you are using the user session. IMO libvirt should just not track any volumes that it can't access for directory pools, reassigning
Hey, we - as a consumer of livemedia-creator / lorax - now run into this issue when we try to do out-of-/tmp builds. Is there maybe a workaround or some progress on this? We try to migrate away from livecd-tools, which makes us rely on livemedia-creator, it would be kind if this bug could be addressed.
Sorry, wrong person to ask :)
Ping? This is preventing libvirt from beeing used in our CI setup.
Fabian, does livemedia-creator use virt-install or something? I wonder what is creating the storage pool. Can you provide the full command you are using that hits this issue, and the error output? I might be able to suggest a workaround Also I'll try to find time to look into a proper fix over the next couple weeks
Hey Cole, yes it is using virt-install. And the commandline I am using is along these lines: $ livemedia-creator --make-disk --ks my.ks --iso boot.iso
Also note that you have to run it as root since it needs to be able to mount filesystems, so this shouldn't be a user session problem. I simplified the problem in comment #1 What I think it boils down to is that it shouldn't even be trying to touch those other files when you've given it a path to a disk image.
Sorry for never getting around to this. I'll post libvirt patches next week and get them into f21+
Patch posted upstream: https://www.redhat.com/archives/libvir-list/2015-April/msg01375.html
Yey, I'm looking forward!
libvirt-1.2.9.3-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/libvirt-1.2.9.3-1.fc21
Package libvirt-1.2.9.3-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.2.9.3-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7150/libvirt-1.2.9.3-1.fc21 then log in and leave karma (feedback).