Red Hat Bugzilla – Bug 1027038
libvirt-manager fails to open install ISO
Last modified: 2013-11-06 13:01:13 EST
Description of problem:
Creating new VM under f20 host.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. virt-manager new VM
2. "Finish" button
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
-rw-rw-r--. 1 qemu qemu 4560257024 Jul 22 14:58 RHEL-7.0-20130628.0-Workstation-x86_64-dvd1.iso
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.