Description of problem: Creating new VM under f20 host. Version-Release number of selected component (if applicable): virt-manager 0.10.0 libvirt.x86_64 0:1.1.3-2.fc20 How reproducible: 100% Steps to Reproduce: 1. virt-manager new VM 2. "Finish" button 3. Actual results: Error popup window: Unable to complete install: 'internal error: process exited while connecting to monitor: Warning: option deprecated, use lost_tick_policy property of kvm-pit instead. qemu-system-x86_64: -drive file=/home/jgh/Downloads/RHEL-7.0-20130628.0-Workstation-x86_64-dvd1.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw: could not open disk image /home/jgh/Downloads/RHEL-7.0-20130628.0-Workstation-x86_64-dvd1.iso: Permission denied doublecheck ISO: -rw-rw-r--. 1 qemu qemu 4560257024 Jul 22 14:58 RHEL-7.0-20130628.0-Workstation-x86_64-dvd1.iso Expected results: Install begins. Additional info: Multiple ISOs tried, from RHEL5.1 to OpenIndiana. Any attempted seems to get chowned qemu:qemu. The kvm-pit issue is bz 978719.
The chown of the iso to qemu:qemu is normal; that is done because the qemu process is run as qemu:qemu (to prevent a compromised qemu process from doing anything nasty). This problem was reported last week in Bug 1025355, and I reproduced it. The issue seems to be that one of the parent directories of the image file (usually /home/$user) is set to mode 710 (or possibly 700) so even changing the owner of the file itself to qemu:qemu doesn't help. virt-manager is supposed to ask if you want to fix this problem, and fix it. *** This bug has been marked as a duplicate of bug 1025355 ***
I realise I'm shouting into the void here, but... these were My Files. Why do you, qemu, go and *steal* them? Perfectly reasonable for you to say "I need this .iso world-readable, and the path searchable". But changing the ownerships? Hey - go the whole hog and move them somewhere else, or encrypt them or something... If it isn't clear, I think you're violating the principle of least astonishment.