FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 04-21-2011, 07:10 PM
Johnny Hughes
 
Default Still a kvm problem after 5.6 upgrade

On 04/21/2011 11:01 AM, 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
>>
>> You should not need to do anything in virsh to dump a file ... there
>> should be an xml file in /etc/libvirt/qemu/ for every VM already.
>
> The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
> should never edit these files directly while the libvirtd service is
> running. You should either use 'virsh edit [vm_name]' or alternatively
> virsh dump followed by virsh define. If you edit the file directly
> while some manager is running (like virt-manager in CentOS), your
> changes will most likely conflict with, or get overwritten by,
> virt-manager. Nothing critical should happen, but I don't see any
> reason for encouraging doing it The Wrong Way(TM).

OK ... I just turn off libvirtd and edit the file, then restart libvirtd
and start the VM.

I am an old school SysIII unix admin, so I just edit files by hand all
the time.

If it is wrong, then I guess doing it right is OK. Though dumping and
importing seem much harder than vi to me.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-21-2011, 07:34 PM
Akemi Yagi
 
Default Still a kvm problem after 5.6 upgrade

On Thu, Apr 21, 2011 at 12:10 PM, Johnny Hughes <johnny@centos.org> wrote:
> On 04/21/2011 11:01 AM, Kenni Lund wrote:

>> The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
>> should never edit these files directly while the libvirtd service is
>> running. You should either use 'virsh edit [vm_name]' or alternatively
>> virsh dump followed by virsh define. If you edit the file directly
>> while some manager is running (like virt-manager in CentOS), your
>> changes will most likely conflict with, or get overwritten by,
>> virt-manager. Nothing critical should happen, but I don't see any
>> reason for encouraging doing it The Wrong Way(TM).
>
> OK ... I just turn off libvirtd and edit the file, then restart libvirtd
> and start the VM.
>
> I am an old school SysIII unix admin, so I just edit files by hand all
> the time.

I hear you :-D

> If it is wrong, then I guess doing it right is OK.

If what I have seen/read is correct, 'virsh edit' has an additional
feature. It will check for errors upon exit. So, it's much like visudo
(versus vi).

When you move kvm guests across different platforms (for example
Fedora to CentOS), editing config files using 'virsh edit' will help.
In this case, you will be running 'virsh define' which may also have a
checking mechanism (not quite sure about this though).

Akemi
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-22-2011, 01:09 AM
David McGuffey
 
Default Still a kvm problem after 5.6 upgrade

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
> >
> > You should not need to do anything in virsh to dump a file ... there
> > should be an xml file in /etc/libvirt/qemu/ for every VM already.
>
> The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
> should never edit these files directly while the libvirtd service is
> running. You should either use 'virsh edit [vm_name]' or alternatively
> virsh dump followed by virsh define. If you edit the file directly
> while some manager is running (like virt-manager in CentOS), your
> changes will most likely conflict with, or get overwritten by,
> virt-manager. Nothing critical should happen, but I don't see any
> reason for encouraging doing it The Wrong Way(TM).
>
> Best regards
> Kenni

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'

I'm going to create /.autorelable and reboot to ensure the upgrade
properly relabled the filesystems.


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.

Allowing Access:

Sometimes labeling problems can cause SELinux denials. You could try to
restore
the default system file context for /dev/hda,

restorecon -v '/dev/hda'

If this does not work, there is currently no automatic way to allow this
access.
Instead, you can generate a local policy module to allow this access -
see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can
disable
SELinux protection altogether. Disabling SELinux protection is not
recommended.
Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context system_u:system_ram_console_t:SystemLow-
SystemHigh
Target Context system_ubject_r:virt_content_t
Target Objects /dev/hda [ blk_file ]
Source pam_console_app
Source Path /sbin/pam_console_apply
Port <Unknown>
Host desk@mydomain.net
Source RPM Packages pam-0.99.6.2-6.el5_5.2
Target RPM Packages
Policy RPM selinux-policy-2.4.6-300.el5
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name catchall_file
Host Name desk@mydomain.net
Platform Linux desk@mydomain.net
2.6.18-238.9.1.el5
#1 SMP Tue Apr 12 18:10:13 EDT 2011 x86_64
x86_64
Alert Count 48
First Seen Wed 13 Apr 2011 08:41:32 AM EDT
Last Seen Thu 21 Apr 2011 07:05:23 AM EDT
Local ID 9ee6c9a9-3eda-4082-84d3-5741ea9ff688
Line Numbers

Raw Audit Messages

host= desk@mydomain.net type=AVC msg=audit(1303383923.130:356): avc:
denied { getattr } for pid=15025 comm="pam_console_app"
path="/dev/hda" dev=tmpfs ino=6206
scontext=system_u:system_ram_console_t:s0-s0:c0.c1023
tcontext=system_ubject_r:virt_content_t:s0 tclass=blk_file

host= desk@mydomain.net type=SYSCALL msg=audit(1303383923.130:356):
arch=c000003e syscall=4 success=no exit=-13 a0=7fff2014b170
a1=7fff2014b1a0 a2=7fff2014b1a0 a3=18cba490 items=0 ppid=15014 pid=15025
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="pam_console_app"
exe="/sbin/pam_console_apply"
subj=system_u:system_ram_console_t:s0-s0:c0.c1023 key=(null)

Dave M



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-22-2011, 01:47 AM
David McGuffey
 
Default Still a kvm problem after 5.6 upgrade

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
> > >
> > > You should not need to do anything in virsh to dump a file ... there
> > > should be an xml file in /etc/libvirt/qemu/ for every VM already.
> >
> > The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
> > should never edit these files directly while the libvirtd service is
> > running. You should either use 'virsh edit [vm_name]' or alternatively
> > virsh dump followed by virsh define. If you edit the file directly
> > while some manager is running (like virt-manager in CentOS), your
> > changes will most likely conflict with, or get overwritten by,
> > virt-manager. Nothing critical should happen, but I don't see any
> > reason for encouraging doing it The Wrong Way(TM).
> >
> > Best regards
> > Kenni
>
> 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'
>
> I'm going to create /.autorelable and reboot to ensure the upgrade
> properly relabled the filesystems.
>
>
> 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.
>
> Allowing Access:
>
> Sometimes labeling problems can cause SELinux denials. You could try to
> restore
> the default system file context for /dev/hda,
>
> restorecon -v '/dev/hda'
>

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


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-22-2011, 10:18 AM
Daniel J Walsh
 
Default Still a kvm problem after 5.6 upgrade

-----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
>>>>
>>>> You should not need to do anything in virsh to dump a file ... there
>>>> should be an xml file in /etc/libvirt/qemu/ for every VM already.
>>>
>>> The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
>>> should never edit these files directly while the libvirtd service is
>>> running. You should either use 'virsh edit [vm_name]' or alternatively
>>> virsh dump followed by virsh define. If you edit the file directly
>>> while some manager is running (like virt-manager in CentOS), your
>>> changes will most likely conflict with, or get overwritten by,
>>> virt-manager. Nothing critical should happen, but I don't see any
>>> reason for encouraging doing it The Wrong Way(TM).
>>>
>>> Best regards
>>> Kenni
>>
>> 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'
>>
>> I'm going to create /.autorelable and reboot to ensure the upgrade
>> properly relabled the filesystems.
>>
>>
>> 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.
>>
>> Allowing Access:
>>
>> Sometimes labeling problems can cause SELinux denials. You could try to
>> restore
>> the default system file context for /dev/hda,
>>
>> restorecon -v '/dev/hda'
>>
>
> 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
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2xVdgACgkQrlYvE4MpobOAGwCfW9TiLJYsyt vvoPl3Kcxfz7w6
iA8An2+Qt0QrKTzp3CyCRVu+sJIKe7wn
=JblK
-----END PGP SIGNATURE-----
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-22-2011, 10:50 AM
David McGuffey
 
Default Still a kvm problem after 5.6 upgrade

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.

Dave M

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-23-2011, 11:51 AM
David McGuffey
 
Default Still a kvm problem after 5.6 upgrade

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_ubject_r:device_t cdrom-hda
lrwxrwxrwx root root system_ubject_r:device_t cdrw-hda
lrwxrwxrwx root root system_ubject_r:device_t cdwriter-hda
lrwxrwxrwx root root system_ubject_r:device_t dvd-hda
lrwxrwxrwx root root system_ubject_r:device_t dvdrw-hda
lrwxrwxrwx root root system_ubject_r:device_t dvdwriter-hda
brw------- dave disk system_ubject_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@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-25-2011, 12:58 PM
Daniel J Walsh
 
Default Still a kvm problem after 5.6 upgrade

-----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@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_ubject_r:device_t cdrom-hda
> lrwxrwxrwx root root system_ubject_r:device_t cdrw-hda
> lrwxrwxrwx root root system_ubject_r:device_t cdwriter-hda
> lrwxrwxrwx root root system_ubject_r:device_t dvd-hda
> lrwxrwxrwx root root system_ubject_r:device_t dvdrw-hda
> lrwxrwxrwx root root system_ubject_r:device_t dvdwriter-hda
> brw------- dave disk system_ubject_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@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-----
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 04:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org