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. Dave M