Red Hat Bugzilla – Bug 1016657
virt-manager's 'New VM' wizard fails when an ISO image is located in user's home directory
Last modified: 2013-11-10 11:47:08 EST
Description of problem: I was following the F20 Virtualization Test Day instructions and installed F20 Beta TC2, followed by 'yum groupinstall virtualization'. Then I tried to use the virt-manager's 'New VM' wizard to install the same F20 Beta TC2 as a virtual machine. I put the ISO file into $HOME/Downloads and pointed the wizard to it. The wizard failed after pressing "Finish" with the following error: 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/tadej/Downloads/Fedora-Live-Desktop-x86_64-20-Beta-TC2.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw: could not open disk image /home/tadej/Downloads/Fedora-Live-Desktop-x86_64-20-Beta-TC2.iso: Permission denied ' For details also see the attached virt-manager.log. Version-Release number of selected component (if applicable): virt-manager-0.10.0-4.git79196cdf.fc20.noarch Actual results: Creating a new VM failed. Expected results: Virt-manager would ask the user if it is allowed to change the appropriate permissions so that the ISO in $HOME/Downloads could be used for creating a new VM. Additional info: [tadej@EliteBook-F20 ~]$ ls -ld $HOME drwx--x---+ 1 tadej tadej 432 Oct 8 14:50 /home/tadej [tadej@EliteBook-F20 ~]$ ls -ld $HOME/Downloads drwxr-xr-x. 1 tadej tadej 84 Oct 8 14:27 /home/tadej/Downloads [tadej@EliteBook-F20 ~]$ getfacl $HOME getfacl: Removing leading '/' from absolute path names # file: home/tadej # owner: tadej # group: tadej user::rwx user:root:--x group::--- mask::--x other::--- [tadej@EliteBook-F20 ~]$ getfacl $HOME/Downloads getfacl: Removing leading '/' from absolute path names # file: home/tadej/Downloads # owner: tadej # group: tadej user::rwx group::r-x other::r-x [tadej@EliteBook-F20 ~]$ cd $HOME/Downloads [tadej@EliteBook-F20 ~]$ ls -alZ Fedora-Live-Desktop-x86_64-20-Beta-TC2.iso -rw-rw-r--. qemu qemu system_u:object_r:virt_content_t:s0 Fedora-Live-Desktop-x86_64-20-Beta-TC2.iso Turning of SELinux via 'sudo setenforce 0' had no effect, the wizard returned the same error. As a work-around, I moved the ISO to /var/lib/libvirt/images directory and then all worked smoothly.
Created attachment 809285 [details] ~/.cache/virt-manager/virt-manager.log
I have the same problem, same version. Oct 09 19:42:18 f20s.localdomain libvirtd[747]: libvirt version: 1.1.3, package: 2.fc20 (Fedora Project, 2013-10-06-19:24:41, buildvm-11.phx2.fedoraproject.org) Oct 09 19:42:18 f20s.localdomain libvirtd[747]: failed to connect to monitor socket: No such process Oct 09 19:42:18 f20s.localdomain libvirtd[747]: 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/chris/Documents/Fedora-Live-Desktop-x86_64-20-Beta-TC2.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw: could not open disk image /home/chris/Documents/Fedora-Live-Desktop-x86_64-20-Beta-TC2.iso: Permission denied The permissions on the ISO are: -rwxr-xr-x. qemu qemu system_u:object_r:virt_content_t:s0 Fedora-Live-Desktop-x86_64-20-Beta-TC2.iso If I move the file to /var/lib/libvirt/images I no longer get the error.
Pretty sure this is the same root issue as bz 1016825, our build configuration isn't sticking. We use build flags to tell virt-manager that Fedora libvirt defaults to running qemu as qemu:qemu, we then check the selected disk images/media to ensure that the VM will be able to access, and offer to fix if not. That offer would have solved this problem
I did get the offer to fix something related to permissions for the directory the ISO was located in, which I agreed to, but I still encountered the problem.
*** This bug has been marked as a duplicate of bug 1025355 ***