Bug 1027038 - libvirt-manager fails to open install ISO
libvirt-manager fails to open install ISO
Status: CLOSED DUPLICATE of bug 1025355
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-11-05 19:11 EST by Jeremy Harris
Modified: 2013-11-06 13:01 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-06 04:08:21 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeremy Harris 2013-11-05 19:11:46 EST
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:

Steps to Reproduce:
1. virt-manager new VM
2. "Finish" button

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.
Comment 1 Laine Stump 2013-11-06 04:08:21 EST
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 ***
Comment 2 Jeremy Harris 2013-11-06 13:01:13 EST
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.

Note You need to log in before you can comment on or make changes to this bug.