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