Created attachment 569498 [details] terminal logs I'm testing Gnome-Boxes with different ISO Images, but every Test ends in "Box Creation failed" Version-Number 3.3.90-1 How reproducible: On every Test Steps to Reproduce: 1. After "Create new Box" Selecting an ISO Image 2. 3. Actual results: "Box creation failed" Expected results: Coming to the next Step to create a Box
Boxes-WARNING **: wizard.vala:156: Unable to start domain: unsupported configuration: Domain requires KVM, but it is not available. Check that virtualization is enabled in the host BIOS, and host configuration is setup to load the kvm modules. This is the reason for the failure. Is kvm_intel/kvm_amd loaded?
Thx for your Answer.. no the Module is not loaded. I've also found this Issue in the Gnome-Boxes Mailing List http://mail.gnome.org/archives/gnome-boxes-list/2012-March/msg00008.html Maybe a Kernel Issue
I would like to confirm this bug. I tried to create both a Windows Xp and many different linux vms, but they would always fail. I tried to reload both kvm_intel and libvirtd without success.
Version 3.3.92 should have reached the repositories by now. Can you try it, and if it still fails, run gnome-boxes --checks and report what it says?
The gnome-boxes --checks gave only Yes. I found that I disable SELinux I am able to create and run the VMs flawlessly. It seem it was a problem the "access_write" permissions from both the ISO and the host directory of the created VM. I think that it's nether normal this kind of error, principally since virt-manager doesn't raise no warms/errors and the source of the bug, according to ABRT, was qemu-kvm, nor well explained the program itself should state why the Vm creation failed, but this is the programming fault. I only gave it a try and overall didn't like the program but couldn't it be less "provoking" to SELinux? Who knows, maybe using the same rules virt-manager uses, since they are share most of the same technology...
Could you look in audit.log for the failures that selinux reported?
Created attachment 573364 [details] Alert generated by box creation
I just added the alert generated on my workstation, but as i read it it doesn't seem to be the same log than before, maybe because it was just updated?
I'm surprised that it's qemu-system-x86_64 that is reporting the error and not qemu-kvm, do you have any idea why this is happening?
You see, I have a Notebook at home with F17 64b and a workstation at my office with F17 32b. Both are Intel, and they gave me completely different errors! The one I sent earlier was from my workstation and I just reinstalled F17 only to try to find an answer(I don't even know why...), well, right now I have two alerts being given from qemu_kvm to any kind of machine I want to create, Unix or Windows, which are: 1 - Write access to ~/.libvirt/qemu/log/*log 2 - Write access to directory lib(what lib?? I have no clue at all!) Since I don't realy know anything about 2, I tried checking 1, and I got this: 1 - Every file belongs to the "sander" user and group; 2 - Change the directory owner to qemu changed nothing; 3 - Either the image being from /home or from a external HDD gives the same error; 4 - The format of the partition makes no difference; 5 - Sometimes ABRT will just not give me any alert, but the creation will fail; 6 - The WXP VM wil actually appear on the principal GUI, but won't boot and the little wheel on the top right corner will stop working(damned interface, what the heell this even means?) 7 - The logs don't give an error code or anything, from what I have seem. I don't know much about either ABRT and QEMU, but could you at least give some idea at what I should look and look for? I greatly doubt that I am the only one with this error, maybe I am one of the few who actually cared about it and, but man, I'm quite lost with this one... Anyway I will attach the logs I got, thanks for caring.
Created attachment 573491 [details] Write access error to lib
Created attachment 573492 [details] Write access error to Windows-XP.log
Created attachment 573494 [details] The log generated by qemu_kvm who is mentioned by the error
Do I understand correctly that all of your problems are related to SELinux, and that if you disable SELinux you are able to create and use a VM?
Yes, exactly, I even stated before, the real question is that the error appears with gnome-boxes and not other qemu-related programs (qemu itself and virt-manager). I don't want to bother, I really don't know the reason I got those errors and as I have interest in use SELinux on the both machines I would rather find a fix than ignore the problem, if possible.
(In reply to comment #15) > Yes, exactly, I even stated before, the real question is that the error appears > with gnome-boxes and not other qemu-related programs (qemu itself and > virt-manager). That's because they use system libvirt, and system directories, they got permissions policy granted. Sorry for not being very SELinux fluent. I think we could use the help of them, and perhaps even reassign this bug. > I don't want to bother, I really don't know the reason I got those errors and > as I have interest in use SELinux on the both machines I would rather find a > fix than ignore the problem, if possible. That's not bothering me, I would be happy to have a fix for this, as usually I think most of us try to avoid the problem to focus on something else. But since you have pretty good error report, and interest in fixing this, let's find the solution. reassigning to selinux-policy to get some help.
(In reply to comment #16) > (In reply to comment #15) > > Yes, exactly, I even stated before, the real question is that the error appears > > with gnome-boxes and not other qemu-related programs (qemu itself and > > virt-manager). > > That's because they use system libvirt, and system directories, they got > permissions policy granted. Sorry for not being very SELinux fluent. I think we > could use the help of them, and perhaps even reassign this bug. I believe that it may be correct, every time I try to troubleshoot the error given another one appears! That's the kind of program which is quite far from my capacity of comprehension. After giving an analysis to "gnome-boxes --debug" it seams that what is causing the errors are: 1- Box Creation "Boxes-WARNING **: wizard.vala:155: Unable to start domain: failed to create logfile /home/sander/.libvirt/qemu/log/Fedora-17-Nightly-20120324.12-i686-Live-desktop.iso.log: Permission denied" 2 - Box Execution "Boxes-WARNING **: libvirt-machine.vala:62: Unable to start domain: failed to create logfile /home/sander/.libvirt/qemu/log/Microsoft Windows XP-1.log: Permission denied" What has bugging me is: 1 - The permission denied since my user belongs to both qemu and kvm groups; 2 - Didn't libvirtd had his own user's group? Or am I confusing with Ubuntu/ArchLinux?
*** Bug 807872 has been marked as a duplicate of this bug. ***
*** Bug 807802 has been marked as a duplicate of this bug. ***
So $ ps -eZ |grep libvirt system_u:system_r:virtd_t:s0-s0:c0.c1023 713 ? 00:00:05 libvirtd staff_u:staff_r:staff_t:s0-s0:c0.c1023 21270 ? 00:00:02 libvirtd $ sh-4.2# ps -eZ |grep gnome-box staff_u:staff_r:staff_t:s0-s0:c0.c1023 21262 ? 00:00:07 gnome-boxes --- allow staff_t kvm_device_t:chr_file { read write ioctl open }; allow staff_t svirt_image_t:file { read relabelto unlink open }; allow staff_t svirt_t:process { transition signull }; allow staff_t svirt_t:unix_stream_socket connectto; #!!!! This avc can be allowed using the boolean 'user_tcp_server' allow staff_t vnc_port_t:tcp_socket name_bind; allow svirt_t user_home_t:dir { write add_name }; allow svirt_t user_home_t:file write; allow svirt_t user_home_t:sock_file create; --
(In reply to comment #10) > 2 - Write access to directory lib(what lib?? I have no clue at all!) http://docs.fedoraproject.org/en-US/Fedora/13/html/SELinux_FAQ/index.html#id4626381 I think this refers to /home/sander/.libvirt/qemu/lib/ which is present on qemu command line
How is libvirtd spawned?
gnome-boxes linked to libvirt, which will automatically spawn libvirtd when needed. This is a session libvirtd (ran as the current user) as opposed to the system libvirtd which is running as root, and started during system startup by systemd.
Miroslav, I think we want a boolean that does staff_use_libvirt Which would add the libvirt rules to staff_t, Allow it to launch svirt_t processes and relabel content.
I'm seeing these issues (along with Bug #809910) when running gnome-boxes on a fresh F17 pre-beta install with selinux-policy-3.10.0-110.fc17.noarch. This socket lives in ~/.libvirt/qemu/lib/ type=AVC msg=audit(1333556927.211:755): avc: denied { write } for pid=25939 comm="qemu-kvm" name="lib" dev="dm-2" ino=1055522 scontext=system_u:system_r:svirt_t:s0:c307,c454 tcontext=unconfined_u:object_r:virt_home_t:s0 tclass=dir type=AVC msg=audit(1333556927.211:755): avc: denied { add_name } for pid=25939 comm="qemu-kvm" name="Fedora-17-Beta-x86_64-Live-XFCE.iso-1.monitor" scontext=system_u:system_r:svirt_t:s0:c307,c454 tcontext=unconfined_u:object_r:virt_home_t:s0 tclass=dir type=AVC msg=audit(1333556927.211:755): avc: denied { create } for pid=25939 comm="qemu-kvm" name="Fedora-17-Beta-x86_64-Live-XFCE.iso-1.monitor" scontext=system_u:system_r:svirt_t:s0:c307,c454 tcontext=system_u:object_r:virt_home_t:s0:c307,c454 tclass=sock_file
commit c536e720f5c5e573cb0517f9db3df0b74bb27811 Author: Miroslav Grepl <mgrepl> Date: Thu Apr 5 09:29:58 2012 +0000 Allow svirt to create monitors in ~/.libvirt
selinux-policy-3.10.0-114.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-114.fc17
Package selinux-policy-3.10.0-114.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-114.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-5870/selinux-policy-3.10.0-114.fc17 then log in and leave karma (feedback).
selinux-policy-3.10.0-114.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Did a clean install from yesterday release and with all the versionstried (Kde & Gnome, x86 & x86_64) and couldn't find a problem at all. For me the bug is cleared. Thanks for everyone who worked this out and sorry for the late reply!
(In reply to comment #30) > Did a clean install from yesterday release and with all the versionstried (Kde > & Gnome, x86 & x86_64) and couldn't find a problem at all. For me the bug is > cleared. I updated my F17 machine today (test-updates repo also enabled) and I failed to create/launch VM because of qemu getting blocked by selinux. `setenforce 0` helped. Would a clean install help?
(In reply to comment #31) > (In reply to comment #30) > > Did a clean install from yesterday release and with all the versionstried (Kde > > & Gnome, x86 & x86_64) and couldn't find a problem at all. For me the bug is > > cleared. > > I updated my F17 machine today (test-updates repo also enabled) and I failed to > create/launch VM because of qemu getting blocked by selinux. `setenforce 0` > helped. Would a clean install help? Probably, can you send the log?
Are selinux policies updated on the fly, or is a reboot needed? I think I had to reboot recently to get a bugfix in selinux-policy to work.
(In reply to comment #33) > Are selinux policies updated on the fly, or is a reboot needed? I think I had > to reboot recently to get a bugfix in selinux-policy to work. Don't know but I did indeed rebooted my machine at least once after the upgrade.
(In reply to comment #33) > Are selinux policies updated on the fly, or is a reboot needed? I think I had > to reboot recently to get a bugfix in selinux-policy to work. Well since mine was a clean install maybe you'll need it, tough i did upgrade/reboot before the install of gnome-boxes
(In reply to comment #31) > (In reply to comment #30) > > Did a clean install from yesterday release and with all the versionstried (Kde > > & Gnome, x86 & x86_64) and couldn't find a problem at all. For me the bug is > > cleared. > > I updated my F17 machine today (test-updates repo also enabled) and I failed to > create/launch VM because of qemu getting blocked by selinux. `setenforce 0` > helped. Would a clean install help? what does $ ausearch -m avc -su virtd_t |audit2allow
I just rebooted the machine and tried to create a VM in Boxes. I was stopped by selinux and here is the info in the 'details' section of the security warning: -------Log------------------------------------------------------------ SELinux is preventing /usr/bin/qemu-kvm from write access on the file /home/zeenix/.libvirt/qemu/log/Fedora 17-1.log. ***** Plugin leaks (86.2 confidence) suggests ****************************** If you want to ignore qemu-kvm trying to write access the Fedora 17-1.log file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # grep /usr/bin/qemu-kvm /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp ***** Plugin catchall (14.7 confidence) suggests *************************** If you believe that qemu-kvm should be allowed write access on the Fedora 17-1.log file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep qemu-kvm /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:svirt_t:s0:c260,c982 Target Context unconfined_u:object_r:virt_home_t:s0 Target Objects /home/zeenix/.libvirt/qemu/log/Fedora 17-1.log [ file ] Source qemu-kvm Source Path /usr/bin/qemu-kvm Port <Unknown> Host z-desktop Source RPM Packages qemu-system-x86-1.0-15.fc17.x86_64 Target RPM Packages Policy RPM selinux-policy-3.10.0-116.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name z-desktop Platform Linux z-desktop 3.3.2-8.fc17.x86_64 #1 SMP Sat Apr 21 12:44:25 UTC 2012 x86_64 x86_64 Alert Count 1 First Seen Wed 25 Apr 2012 04:08:47 PM EEST Last Seen Wed 25 Apr 2012 04:08:47 PM EEST Local ID 3e23a415-4208-4e0f-a198-cd16229c6c5b Raw Audit Messages type=AVC msg=audit(1335359327.238:93): avc: denied { write } for pid=1810 comm="qemu-kvm" path=2F686F6D652F7A65656E69782F2E6C6962766972742F71656D752F6C6F672F4665646F72612031372D312E6C6F67 dev="dm-2" ino=14420562 scontext=system_u:system_r:svirt_t:s0:c260,c982 tcontext=unconfined_u:object_r:virt_home_t:s0 tclass=file type=AVC msg=audit(1335359327.238:93): avc: denied { write } for pid=1810 comm="qemu-kvm" path=2F686F6D652F7A65656E69782F2E6C6962766972742F71656D752F6C6F672F4665646F72612031372D312E6C6F67 dev="dm-2" ino=14420562 scontext=system_u:system_r:svirt_t:s0:c260,c982 tcontext=unconfined_u:object_r:virt_home_t:s0 tclass=file type=SYSCALL msg=audit(1335359327.238:93): arch=x86_64 syscall=execve success=yes exit=0 a0=7f5e180032d0 a1=7f5e18003780 a2=7f5e18002c10 a3=7f5e3d9c2870 items=0 ppid=1 pid=1810 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm=qemu-kvm exe=/usr/bin/qemu-kvm subj=system_u:system_r:svirt_t:s0:c260,c982 key=(null) Hash: qemu-kvm,svirt_t,virt_home_t,file,write audit2allowunable to open /sys/fs/selinux/policy: Permission denied audit2allow -Runable to open /sys/fs/selinux/policy: Permission denied ------------------------------------------------------------------------ (In reply to comment #36) > what does > > $ ausearch -m avc -su virtd_t |audit2allow $ ausearch -m avc -su virtd_t |audit2allow Error opening config file (Permission denied) NOTE - using built-in logs: /var/log/audit/audit.log Error opening /var/log/audit/audit.log (Permission denied) WARNING: Policy would be downgraded from version 27 to 26. Nothing to do
Run it as root.
I updated my machine again and rebooted. I don't see any selinux issues anymore with Boxes. The box creation works but launching it doesn't succeed but from the log it seems like some libvirt issue.
(In reply to comment #39) > I updated my machine again and rebooted. I don't see any selinux issues anymore > with Boxes. The box creation works but launching it doesn't succeed but from > the log it seems like some libvirt issue. Actually its still selinux blocking us in some way. If I set it to permissive, box creation and launched works nicely. Here is the output requested (ran as root): # ausearch -m avc -su virtd_t |audit2allow ERROR: policydb magic number 0x000008 does not match expected magic number 0xf97cff8c or 0xf97cff8d ERROR: Unable to open policy /sys/fs/selinux/policy. <no matches> Nothing to do
I think this really shouldn't require clean install and an update should fix the problem. Hence re-opening..
I am reverting a fix to setools which is causing the policydb magic number problem. Could you just attach the # ausearch -m avc -su virtd_t messages.
FWIW, I've never had selinux enabled to begin with (it's set to disabled in /etc/selinux/config), yet I'm still unable to start the creation of a VM in gnome-boxes with an iso file. I always get this in the terminal: Boxes-WARNING **: wizard.vala:154: Unable to start domain: unsupported configuration: Domain requires KVM, but it is not available. Check that virtualization is enabled in the host BIOS, and host configuration is setup to load the kvm modules Different bug?
(In reply to comment #43) > FWIW, I've never had selinux enabled to begin with (it's set to disabled in > /etc/selinux/config), yet I'm still unable to start the creation of a VM in > gnome-boxes with an iso file. I always get this in the terminal: > > Boxes-WARNING **: wizard.vala:154: > Unable to start domain: unsupported configuration: Domain requires KVM, but > it is not available. Check that virtualization is enabled in the host BIOS, > and host configuration is setup to load the kvm modules > > Different bug? Yes, it looks like. I guess this happens also in permissive mode?
(In reply to comment #43) > FWIW, I've never had selinux enabled to begin with (it's set to disabled in > /etc/selinux/config), yet I'm still unable to start the creation of a VM in > gnome-boxes with an iso file. I always get this in the terminal: > > Boxes-WARNING **: wizard.vala:154: > Unable to start domain: unsupported configuration: Domain requires KVM, but > it is not available. Check that virtualization is enabled in the host BIOS, > and host configuration is setup to load the kvm modules > > Different bug? Yes different bug, most likely the kvm_intel/kvm_amd kernel module is not loaded, possibly because virtualization support (or whatever it's called) is disabled in your bios
*** Bug 827932 has been marked as a duplicate of this bug. ***
Is the selinux rules now fixed for Boxes/libvirt? I still get bug reports about this and this bug remains open so I'm guess the answer is 'no'. Boxes totally fails currently in F17 mainly becuase of this bug.
See bug #809910 , dunno if this one is a duplicate or not.
*** This bug has been marked as a duplicate of bug 809910 ***
This is still happening on my 64-bit F17 laptop as of 6 September 2012. I've got all the updates installed. I'll go check out but 809910 but I think that's been fixed as well and I still can't create a box.
If this works with selinux disabled but does not work with selinux enabled, you probably need to run the restorecon command mentioned in bug #809910