Description of problem: When trying to create a new virtual machine, virt-manager bombs with the following dialogue box: Unable to complete install: 'virDomainCreateLinux() failed internal error QEMU quit during console startup qemu: could not open disk image /home/jgu/w32/WindowsXP/WindowsXP.iso ' The backtrace is: Unable to complete install '<class 'libvirt.libvirtError'> virDomainCreateLinux() failed internal error QEMU quit during console startup qemu: could not open disk image /home/jgu/w32/WindowsXP/WindowsXP.iso Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 651, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 845, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 866, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.5/site-packages/libvirt.py", line 833, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: virDomainCreateLinux() failed internal error QEMU quit during console startup qemu: could not open disk image /home/jgu/w32/WindowsXP/WindowsXP.iso ' The SElinux avc denial messages are: Summary: SELinux is preventing the qemu-system-x86 from using potentially mislabeled files (./WindowsXP.iso). Detailed Description: SELinux has denied qemu-system-x86 access to potentially mislabeled file(s) (./WindowsXP.iso). This means that SELinux will not allow qemu-system-x86 to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want qemu-system-x86 to access this files, you need to relabel them using restorecon -v './WindowsXP.iso'. You might want to relabel the entire directory using restorecon -R -v '.'. Additional Information: Source Context unconfined_u:system_r:virtd_t:s0 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects ./WindowsXP.iso [ file ] Source qemu-system-x86 Source Path /usr/bin/qemu-system-x86_64 Port <Unknown> Host withnail.phys.ucl.ac.uk Source RPM Packages qemu-0.9.1-5.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-62.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name home_tmp_bad_labels Host Name withnail.phys.ucl.ac.uk Platform Linux withnail.phys.ucl.ac.uk 2.6.25.4-30.fc9.x86_64 #1 SMP Wed May 21 17:34:18 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Tue 10 Jun 2008 12:20:28 PM BST Last Seen Tue 10 Jun 2008 12:20:28 PM BST Local ID 7e627683-dda4-4b19-a4a0-581e061cf75e Line Numbers Raw Audit Messages host=withnail.phys.ucl.ac.uk type=AVC msg=audit(1213096828.902:1858): avc: denied { read } for pid=29767 comm="qemu-system-x86" name="WindowsXP.iso" dev=dm-1 ino=11829530 scontext=unconfined_u:system_r:virtd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file host=withnail.phys.ucl.ac.uk type=SYSCALL msg=audit(1213096828.902:1858): arch=c000003e syscall=2 success=no exit=-13 a0=7fff76f5ce30 a1=0 a2=1a4 a3=3714d67a70 items=0 ppid=29646 pid=29767 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=207 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=unconfined_u:system_r:virtd_t:s0 key=(null) Summary: SELinux is preventing the qemu-system-x86 from using potentially mislabeled files (/home/jgu/w32/WindowsXP/WindowsXP.iso). Detailed Description: SELinux has denied qemu-system-x86 access to potentially mislabeled file(s) (/home/jgu/w32/WindowsXP/WindowsXP.iso). This means that SELinux will not allow qemu-system-x86 to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want qemu-system-x86 to access this files, you need to relabel them using restorecon -v '/home/jgu/w32/WindowsXP/WindowsXP.iso'. You might want to relabel the entire directory using restorecon -R -v '/home/jgu/w32/WindowsXP'. Additional Information: Source Context unconfined_u:system_r:virtd_t:s0 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects /home/jgu/w32/WindowsXP/WindowsXP.iso [ file ] Source qemu-system-x86 Source Path /usr/bin/qemu-system-x86_64 Port <Unknown> Host withnail.phys.ucl.ac.uk Source RPM Packages qemu-0.9.1-5.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-62.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name home_tmp_bad_labels Host Name withnail.phys.ucl.ac.uk Platform Linux withnail.phys.ucl.ac.uk 2.6.25.4-30.fc9.x86_64 #1 SMP Wed May 21 17:34:18 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Tue 10 Jun 2008 12:20:28 PM BST Last Seen Tue 10 Jun 2008 12:20:28 PM BST Local ID 887bf1c9-eae9-432f-9eff-9d6170d1ae3a Line Numbers Raw Audit Messages host=withnail.phys.ucl.ac.uk type=AVC msg=audit(1213096828.902:1857): avc: denied { getattr } for pid=29767 comm="qemu-system-x86" path="/home/jgu/w32/WindowsXP/WindowsXP.iso" dev=dm-1 ino=11829530 scontext=unconfined_u:system_r:virtd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file host=withnail.phys.ucl.ac.uk type=SYSCALL msg=audit(1213096828.902:1857): arch=c000003e syscall=4 success=no exit=-13 a0=7fff76f5ce30 a1=7fff76f5a420 a2=7fff76f5a420 a3=0 items=0 ppid=29646 pid=29767 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=207 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=unconfined_u:system_r:virtd_t:s0 key=(null) It's clear what is going on here - the install media iso doesn't have the SElinux label required by the SElinux policy. However, the situation is pretty badly handled, I think. First off, virt-manager should test for this problem before allocating the disk space. It should then also suggest some kind of work around, eg. suggesting that the file be relabelled with the correct label, whatever that is - in fact this could be optionally done by virt manager. On the third hand, I think this SElinux policy restriction is a bit overly prohibitive. Anyway, the user experience could be improved a lot here! Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Opps, hit submit too early. Further info: # rpm -qa | grep virt libvirt-python-0.4.2-4.fc9.x86_64 virt-manager-0.5.4-4.fc9.x86_64 libvirt-0.4.2-4.fc9.x86_64 python-virtinst-0.300.3-7.fc9.noarch # rpm -qa | grep selinux libselinux-2.0.64-2.fc9.x86_64 selinux-policy-3.3.1-62.fc9.noarch libselinux-python-2.0.64-2.fc9.x86_64 libselinux-2.0.64-2.fc9.i386 selinux-policy-targeted-3.3.1-62.fc9.noarch
I tend to disagree, the two are mutually exclusive. VMM doesn't know about the .iso to be used nor should it really be responsible for it, that should be the users responsibility. As for the SELinux labeling, I agree, it should inherit the labels from the home directory, why it doesn't I am not sure. It is a simple fix though.
The iso did have the label expected for a file in a user home directory though - the point is that the SElinux policy as shipped requires an entirely different label for the iso file for it to work with virt-manager (virtd_t). AFAIK, there are no directives anywhere to tell the user to relabel his iso file to virtd_t before attempting to use it to create a virtual machine. What I'd like to see is virt-manager popping up a dialogue box saying "The iso file you have chosen for the install media has the wrong SElinux label. Would you like me to label this file with the correct label?". Or at the very least, "The iso image has the wrong SElinux label, please ensure it is labelledd as virtd_t". Really, if the SElinux policy is going to get this restrictive, applications have to start being able to cope with SElinux denials cleanly, and not bombing out. Also, virt-manager should check it can access the iso file *before* allocating the image for the virtual machine, surely - in this case i waited for a few minutes for a 10 GB disk image to be created.
I agree that this decision was not communicated clearly and we should attempt to accomodate this in virt-manager in some way. A workaround should be to place the iso file in /var/lib/libvirt/images which should have the correct labelling. See http://danwalsh.livejournal.com/16589.html for some more info.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.