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@xxxxxxxxxx>:
> > >>>> 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@desk dev]# cd /etc/libvirt/qemu
>
> [root@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@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@desk ~]# cd /dev/
[root@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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
