I am trying to set up a test kvm virtual machine on a core2 quad system. I have managed to thread my way through bridging eth0 and I have a CentOS-5.4 dvd iso prepared.
Using virt-manager, when I try and add a new guest then I get the error reproduced below. Now, I know that I can 'fix' this by building a local mod via audit2allow and installing via semodule. However, I cannot seem to find this particular problem when I Google for it. Therefore, it seems likely that I have done something wrong rather than having encountered a bug.
Does anyone have any suggestions as to what step I may have missed in setting up a kvm guest? All I have done so far is:
Install qemu. Set libvirtd to start at boot. Bridge eth0 to br0 via customs ifcfg-X scripts in /etc/sysconfig/network-scripts. Run virt-manager. Add a new guest.
Summary:
SELinux is preventing qemu-system-x86 (qemu_t) "read" to rtc (clock_device_t).
Detailed Description:
SELinux denied access requested by qemu-system-x86. It is not expected that this access is required by qemu-system-x86 and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for rtc,
restorecon -v 'rtc'
If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Additional Information:
Source Context system_u:system_r:qemu_t:SystemLow-SystemHigh Target Context system_u:object_r:clock_device_t Target Objects rtc [ chr_file ] Source qemu-system-x86 Source Path /usr/bin/qemu-system-x86_64 Port <Unknown> Host inet02.hamilton.harte-lyne.ca Source RPM Packages qemu-0.9.0-4 Target RPM Packages Policy RPM selinux-policy-2.4.6-255.el5_4.1 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name inet02.hamilton.harte-lyne.ca Platform Linux inet02.hamilton.harte-lyne.ca 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 Alert Count 1 First Seen Mon 09 Nov 2009 06:28:32 PM EST Last Seen Mon 09 Nov 2009 06:28:32 PM EST Local ID d8ca7ab9-f135-4700-a515-c7b8efba1e27 Line Numbers
Raw Audit Messages
host=inet02.hamilton.harte-lyne.ca type=AVC msg=audit(1257809312.343:21): avc: denied { read } for pid=4166 comm="qemu-system-x86" name="rtc" dev=tmpfs ino=796 scontext=system_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=system_u:object_r:clock_device_t:s0 tclass=chr_file
host=inet02.hamilton.harte-lyne.ca type=SYSCALL msg=audit(1257809312.343:21): arch=c000003e syscall=2 success=no exit=-13 a0=4d8b3c a1=0 a2=0 a3=8 items=0 ppid=1 pid=4166 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=system_u:system_r:qemu_t:s0-s0:c0.c1023 key=(null)
James B. Byrne wrote on Mon, 9 Nov 2009 10:44:36 -0500 (EST):
Install qemu.
SELinux denied access requested by qemu-system-x86.
I'm not running KVM (but Xen). From the snippets above I deduce:
- qemu is not part of CentOS, you probably got it from rpmforge. - that means you do not need qemu for KVM usage - SELinux cannot know about it - there's probably a different preferred way to use KVM on CentOS
Kai
- qemu is not part of CentOS, you probably got it from rpmforge.
- that means you do not need qemu for KVM usage
- SELinux cannot know about it
- there's probably a different preferred way to use KVM on CentOS
From a recent mail in this list:
Well, it turns out that qemu is required and kvm-qemu-img was the source of the problem. Removing this and installing qemu instead fixed the problem.
Actually I did the other way round: yum remove qemu (which is in the extras repo) yum install -x qemu kvm (excluding qemu and thus kvm-qemu-img will be taken)
=> make sure you have 'kvm-qemu-img' installed and not 'qemu', according to Kai's comment above, this may help you
On Mon, November 9, 2009 10:44, James B. Byrne wrote:
I'm not running KVM (but Xen). From the snippets above I deduce:
- qemu is not part of CentOS, you probably got it from rpmforge.
- that means you do not need qemu for KVM usage
- SELinux cannot know about it
- there's probably a different preferred way to use KVM on CentOS
Odd then, do you not think, that when I install virt-manager yum requires qemu from the extras repository and does not require kvm-qemu-img. Odder still that yum seems not to know anything about kvm-qemu-img.
# yum whatprovides */kvm-qemu-img Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: centos.mirror.iweb.ca * base: centos.mirror.iweb.ca * extras: centos.mirror.iweb.ca * updates: centos.mirror.iweb.ca No Matches found
# yum install virt-manager Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: mirror.csclub.uwaterloo.ca * base: mirror.csclub.uwaterloo.ca * extras: mirror.csclub.uwaterloo.ca * updates: mirror.csclub.uwaterloo.ca Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package virt-manager.x86_64 0:0.6.1-8.el5 set to be updated --> Processing Dependency: libvirt-python >= 0.3.3 for package: virt-manager --> Processing Dependency: python-virtinst >= 0.400.3 for package: virt-manager --> Running transaction check ---> Package libvirt-python.x86_64 0:0.6.3-20.1.el5_4 set to be updated --> Processing Dependency: libvirt.so.0(LIBVIRT_0.1.0)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.6.1)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.1.9)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.1.1)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.6.3)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.2.0)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.5.0)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.4.1)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.1.4)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.2.3)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.3.0)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.1.5)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.4.0)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.0.3)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.6.0)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.3.3)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.2.1)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.0.5)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.4.5)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0(LIBVIRT_0.3.2)(64bit) for package: libvirt-python --> Processing Dependency: libvirt.so.0()(64bit) for package: libvirt-python ---> Package python-virtinst.noarch 0:0.400.3-5.el5 set to be updated --> Running transaction check ---> Package libvirt.x86_64 0:0.6.3-20.1.el5_4 set to be updated --> Processing Dependency: /usr/bin/qemu-img for package: libvirt --> Running transaction check ---> Package qemu.x86_64 0:0.9.0-4 set to be updated --> Finished Dependency Resolution
Dependencies Resolved
================================================================================ Package Arch Version Repository Size ================================================================================ Installing: virt-manager x86_64 0.6.1-8.el5 base 1.5 M Installing for dependencies: libvirt x86_64 0.6.3-20.1.el5_4 updates 2.0 M libvirt-python x86_64 0.6.3-20.1.el5_4 updates 133 k python-virtinst noarch 0.400.3-5.el5 base 378 k qemu x86_64 0.9.0-4 extras 4.5 M
Transaction Summary ================================================================================ Install 5 Package(s) Update 0 Package(s) Remove 0 Package(s)
James B. Byrne wrote on Mon, 9 Nov 2009 14:30:21 -0500 (EST):
Odd then, do you not think, that when I install virt-manager yum requires qemu from the extras repository and does not require kvm-qemu-img.
Yes. It doesn't require any of them for me. Have you tried cleaning your metadata?
Kai
I removed qemu and reinstalled virt-manager using the -x qemu switch. Everything installs and I get kvm-qemu-img instead of qemu. Of course, virt-manager now does not work. It opens but it does not provide any means of adding a new virtual host. This places me back at my point of departure, albeit in a much fouler mood.
I am afraid I am not seeing the logic behind this sort of install cockup. If qemu is not supposed to be used at all then why is it even available and why does it install in preference to kvm-qemu-img? If kvm-qemu-img is supposed to be used instead of qemu then why does not virt-manager work with it? If qemu is supposed to be used if one uses virt-manager then why does qemu violate the SELinux profile? If virt-manager is not supposed to be used then why is it available?
Am I missing something obvious here. Is there a way to configure virt-manager or kvm-qemu-img so that they work together?
Sincerely,
Of course, virt-manager now does not work. It opens but it does not provide any means of adding a new virtual host.
What are the symptoms? Does virt-manager ask for your root password when starting?
Did you try with SELinux in permissive mode?
I recommend that you install setroubleshoot, it helps to debug SELinux issues, and will be notified when in permissive mode as well: sudo yum install setroubleshoot
James B. Byrne wrote on Mon, 9 Nov 2009 14:48:50 -0500 (EST):
I am afraid I am not seeing the logic behind this sort of install cockup. If qemu is not supposed to be used at all then why is it even available
because you enabled rpmforge and installed qemu. *You* did that, not CentOS. I suppose you were going by some tutorial that isn't quite right (anymore)?
= Installing: kvm x86_64 83-105.el5_4.9 updates 828 k Installing for dependencies: celt051 x86_64 0.5.1.3-0.el5 base 51 k etherboot-zroms-kvm x86_64 5.4.4-10.el5.centos base 126 k kmod-kvm x86_64 83-105.el5_4.9 updates 1.2 M libogg x86_64 2:1.1.3-3.el5 base 18 k log4cpp x86_64 1.0-4.el5 base 506 k mesa-libGLU x86_64 6.5.1-7.7.el5 base 225 k qcairo x86_64 1.8.7.1-3.el5 base 499 k qffmpeg-libs x86_64 0.4.9-0.15.20080908.el5 base 273 k qpixman x86_64 0.13.3-4.el5 base 109 k qspice-libs x86_64 0.3.0-39.el5_4.3 updates 228 k
see any sign of qemu?
I did the same for virt-manager. Again, no sign of qemu.
I suggest you go to the centos-virt list, your questions are all virtualization- specific. Maybe the archive already helps?
Kai
On Mon, 2009-11-09 at 23:31 +0100, Kai Schaetzl wrote:
James B. Byrne wrote on Mon, 9 Nov 2009 14:48:50 -0500 (EST):
I am afraid I am not seeing the logic behind this sort of install cockup. If qemu is not supposed to be used at all then why is it even available
because you enabled rpmforge and installed qemu. *You* did that, not CentOS. I suppose you were going by some tutorial that isn't quite right (anymore)?
= Installing: kvm x86_64 83-105.el5_4.9 updates 828 k Installing for dependencies: celt051 x86_64 0.5.1.3-0.el5 base 51 k etherboot-zroms-kvm x86_64 5.4.4-10.el5.centos base 126 k kmod-kvm x86_64 83-105.el5_4.9 updates 1.2 M libogg x86_64 2:1.1.3-3.el5 base 18 k log4cpp x86_64 1.0-4.el5 base 506 k mesa-libGLU x86_64 6.5.1-7.7.el5 base 225 k qcairo x86_64 1.8.7.1-3.el5 base 499 k qffmpeg-libs x86_64 0.4.9-0.15.20080908.el5 base 273 k qpixman x86_64 0.13.3-4.el5 base 109 k qspice-libs x86_64 0.3.0-39.el5_4.3 updates 228 k
see any sign of qemu?
I did the same for virt-manager. Again, no sign of qemu.
I suggest you go to the centos-virt list, your questions are all virtualization- specific. Maybe the archive already helps?
Kai
Don't be so hard on him.
I did a vanilla install of 5.4 x86_64 and selected 'kvm' as a custom package during install. I didn't go to rpmforge and get any other virtualization tools. kvm and Virtual Machine Manager (the RHEL graphical interface to libvirt) just worked...created a VM with WinXP A-OK.
I do get an sealert from qemu-kvm...so qemu must be embedded in whatever comes with the 'kvm' selection at install time.
I posted the following sealert on the selinux-list:
Summary:
SELinux is preventing qemu-kvm (qemu_t) "read" to sh (bin_t).
Detailed Description:
SELinux denied access requested by qemu-kvm. It is not expected that this access is required by qemu-kvm and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for sh,
restorecon -v 'sh'
If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Additional Information:
Source Context system_u:system_r:qemu_t:SystemLow-SystemHigh Target Context system_u:object_r:bin_t Target Objects sh [ lnk_file ] Source qemu-kvm Source Path /usr/libexec/qemu-kvm Port <Unknown> Host desk Source RPM Packages kvm-83-105.el5_4.9 Target RPM Packages Policy RPM selinux-policy-2.4.6-255.el5_4.1 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name desk Platform Linux desk 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:12:36 EST 2009 x86_64 x86_64 Alert Count 1 First Seen Mon 09 Nov 2009 09:59:41 PM EST Last Seen Mon 09 Nov 2009 09:59:41 PM EST Local ID f52a188e-0710-4238-86ce-af3beb90c318 Line Numbers
Raw Audit Messages
host=desk type=AVC msg=audit(1257821981.730:53): avc: denied { read } for pid=4947 comm="qemu-kvm" name="sh" dev=sdc5 ino=3156772 scontext=system_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file
host=desk type=SYSCALL msg=audit(1257821981.730:53): arch=c000003e syscall=59 success=no exit=-13 a0=31a311f873 a1=7fff15506380 a2=7fff15509f00 a3=31a3e16220 items=0 ppid=4900 pid=4947 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:qemu_t:s0-s0:c0.c1023 key=(null)
Bottom line is that qemu-kvm is present in the 5.4 x86_64 release. And there does seem to be a problem with the policy. Documentation states one should be able to run a VM as a regular user. Virtual Machine Manger doesn't have any options to create a VM for a non-root user to run. Looking at the xml in the /etc/libvirt folder, it is clear that the permissions of the created images are 0700 and root:root. I'm probably going to change those perms to 0660 and root:kvm to see what happens. sealerts won't stop because I haven't modified the policy or the extended file attributes, but it should allow me as a regular user as a member of the kvm group to run the VM.
/////////////////// BTW, I did install yum-priorities and then went to rpmforge to get mplayer and the gstreamer-plugins. Got lots of SELinux alerts from the plugins (see my posts on the selinux-list concerning them).
DaveM
David McGuffey wrote on Mon, 09 Nov 2009 22:44:39 -0500:
Don't be so hard on him.
I'm not trying to. Sorry, if it sounded like that. The point is that James still seems to mix some things in his mind which apparently are not to be mixed. He's to start over to succeed.
Kai
-
David McGuffey -
James B. Byrne -
Kai Schaetzl -
Mathieu Baudier