-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/23/2011 07:51 AM, David McGuffey wrote: > > On Fri, 2011-04-22 at 06:50 -0400, David McGuffey wrote: >> On Fri, 2011-04-22 at 06:18 -0400, Daniel J Walsh wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 04/21/2011 09:47 PM, David McGuffey wrote: >>>> >>>> On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote: >>>>> On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote: >>>>>> 2011/4/21 Johnny Hughes <johnny at centos.org>: >>>>>>> On 04/21/2011 06:11 AM, David McGuffey wrote: >>>>>>>> redlibvirtError: internal error Process exited while reading console log >>>>>>>> output: qemu: could not open disk image /dev/hda >>>>>>> >>>>> >>>>> Problem may be an SELinux problem. Here is the alert. Notice the >>>>> reference to '/dev/hda' (which is the virtual machine boot disk), and >>>>> the SELinux context 'virt_content_t' >>>>> >>>>> Summary: >>>>> >>>>> SELinux is preventing pam_console_app (pam_console_t) "getattr" >>>>> to /dev/hda >>>>> (virt_content_t). >>>>> >> ... >>>>> Detailed Description: >>>>> >>>>> SELinux denied access requested by pam_console_app. It is not expected >>>>> that this >>>>> access is required by pam_console_app 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. >>>>> >> ... >>>> >>>> Yep...each time I try to start the VM, sealert increments this error by >>>> one. >>>> >>>> I created /.autorelable and rebooted. SELinux relabeled everything, but >>>> the sealert still fires when I try to start the VM. >>>> >>>> I did a qemu-img <path_to_vm>/vm.img and the format is declared 'raw' >>>> Therefore I should not be editing the vm.xml file and changing 'raw' to >>>> 'qcow2' >>>> >>>> Problem is definately with the SELlnux labels in the 5.6 upgrade. >>>> >>>> Dave M >>>> >>>> >> ... >>> This is an SELinux issue. It really has no effect on the virtual >>> machine. The problem is the label is not something pam_console policy >>> expected to have on a blk device. >> >> Yes, I was lured by the coincidence of the sealert and my effort to >> start the VM. The fact that the blk device in question happens to >> register as /dev/hda and the VM also uses an internal "virtual" device >> called /dev/hda can lead one astray. >> >> I'm still left without an answer as to why virsh won't create or >> define-->start a VM after the upgrade. >> >> [root at desk dev]# cd /etc/libvirt/qemu >> >> [root at desk qemu]# virsh create Win7-base.xml >> error: Failed to create domain from Win7-base.xml >> error: internal error Process exited while reading console log output: >> qemu: could not open disk image /dev/hda >> >> using qemu-img against the image file reports 'raw' not 'qcow2' So...I >> should not have to edit the .xml file...it is already correct. >> >> [root at desk images]# qemu-img info Win7-base.img >> image: Win7-base.img >> file format: raw >> virtual size: 29G (31457280000 bytes) >> disk size: 29G >> >> This is not good. I've been developing a prototype which uses several >> VMs under qemu-kvm. I'm now starting to question whether CentOS is the >> right tool to be using for prototyping capability that may eventually >> roll onto regular RHEL. >> > Did some more poking around and this is an SELinux problem. SELinux is > denying access to /dev/hda. /dev/hda turns out to be the CDROM/DVD R/W > device on the EIDE port of the motherboard. Lots of alias devices are > linked to it. > > When I try to start a VM that has a cdrom defined, selinux stops the > access and virsh (and Virtual Machine Manager) will report an error > accessing /dev/hda (the cdrom). Here is the cdrom portion of the xml > > <disk type='block' device='cdrom'> > <driver name='qemu' type='raw'/> > <source dev='/dev/hda'/> > <target dev='hdc' bus='ide'/> > <readonly/> > <address type='drive' controller='0' bus='1' unit='0'/> > </disk> > > As soon as I detached the cdrom device from the VM, the VM starts and > runs A-OK. > > Here is a listing of all the hda devices (blk and links) in /dev > > [root at desk ~]# cd /dev/ > [root at desk dev]# ls -Z |grep hda > lrwxrwxrwx root root system_u:object_r:device_t cdrom-hda > lrwxrwxrwx root root system_u:object_r:device_t cdrw-hda > lrwxrwxrwx root root system_u:object_r:device_t cdwriter-hda > lrwxrwxrwx root root system_u:object_r:device_t dvd-hda > lrwxrwxrwx root root system_u:object_r:device_t dvdrw-hda > lrwxrwxrwx root root system_u:object_r:device_t dvdwriter-hda > brw------- dave disk system_u:object_r:virt_content_t hda > > Notice the selinux context includes 'virt_content_t' I'm not sure this > is right or wrong. > > What is strange is the owner:group of hda is my normal (unprivileged) > user login 'dave' I would have thought it would be root:kvm (where dave > is a member of kvm). > > Methinks either the owner:group or the selinux context of hda is wrong, > or the linked devices may also need to have the 'virt_content_t' > context. > > I just downloaded a fresh 5.6 iso and will build it on a spare machine. > Goal is to see what kind of devices are created and what kind of > owner:group permissions are given and what kind of selinux context is > given to /dev/hda. They may be different from an upgrade. > > All this came up with the upgrade from 5.5 to 5.6, so it is both a > CentOS 5.6 problem and an selinux problem. Should I leave this here or > summarize what I found over on the fedora selinux forum? > > Dave M > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos Try restorecon -RF on the device. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk21b/gACgkQrlYvE4MpobNbNQCeMME1CsmexXYEtnv+dY7Vdwoz 7iEAoMpw7H0l488ihvpblNbXMPmZn+xW =Ojrb -----END PGP SIGNATURE-----