[CentOS] Still a kvm problem after 5.6 upgrade

Mon Apr 25 12:58:32 UTC 2011
Daniel J Walsh <dwalsh at redhat.com>

-----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-----