Bug 902103 - "Cannot parse sensitivity level in s0" when launching nova instance
Summary: "Cannot parse sensitivity level in s0" when launching nova instance
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 18
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-01-20 21:34 UTC by Steve Baker
Modified: 2013-04-11 23:30 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-04-11 23:30:45 UTC
Type: Bug

Attachments (Terms of Use)
libvirt xml which demonstrates problem (1.62 KB, text/plain)
2013-01-20 21:37 UTC, Steve Baker
no flags Details

Description Steve Baker 2013-01-20 21:34:07 UTC
Description of problem:
Since upgrading to Fedora 18 I've not been able to launch nova instances with current master of nova & devstack.

The following error is logged:
"Cannot parse sensitivity level in s0"

Running virsh create on the attached sensitivity_level_fail.xml nova generated XML also reproduces the error.

Version-Release number of selected component (if applicable):

How reproducible:
All the time when svirt is enabled

Steps to Reproduce:
1. Run virsh create sensitivity_level_fail.xml

Actual results:
Immediately fails with error
"Cannot parse sensitivity level in s0"

Expected results:

Additional info:
Workaround is to set:
security_driver = "none"
in /etc/libvirt/qemu.conf

Comment 1 Steve Baker 2013-01-20 21:37:41 UTC
Created attachment 683900 [details]
libvirt xml which demonstrates problem

Comment 2 Daniel Berrangé 2013-01-21 10:16:30 UTC
Please provide 

 ps -axuZ | grep libvirtd


 ls -lZ /usr/sbin/libvirtd

Comment 3 Steve Baker 2013-01-21 20:29:05 UTC
# ps -axuZ | grep libvirtd
system_u:system_r:kernel_t:s0   root       951  0.0  0.0 484324  1824 ?        Ssl  Jan21   0:00 /usr/sbin/libvirtd
unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 root 18159 0.0  0.0 109180 884 pts/6 S+ 09:25   0:00 grep --color=auto libvirtd

# ls -lZ /usr/sbin/libvirtd
-rwxr-xr-x. root root system_u:object_r:virtd_exec_t:s0 /usr/sbin/libvirtd

This is with svirt still disabled

Comment 4 Cole Robinson 2013-01-25 23:25:54 UTC
Hmm, I can't reproduce. That error message comes from libvirtd, trying to parse it's own selinux context. It throws that error if it doesn't find a colon in the context string.

Steve, is this with all up to date packages? Do other VMs work? Is selinux in enforcing, permissive, or disabled?

Also, please provide 

  ps -axuZ | grep libvirtd

again, but this time with svirt enabled, and after restarting libvirtd.

Comment 5 Dave Allan 2013-01-28 17:35:58 UTC
See also BZ 896610

Comment 6 Steve Baker 2013-02-05 00:36:40 UTC
With security_driver = "selinux"
in /etc/libvirt/qemu.conf

ps -axuZ | grep libvirtd
system_u:system_r:kernel_t:s0   root      9438  0.2  0.1 1078160 5856 ?        Ssl  13:27   0:00 /usr/sbin/libvirtd
unconfined_u:system_r:abrt_helper_t:s0-s0:c0.c1023 steveb 15084 0.0  0.0 109180 884 pts/1 S+ 13:33   0:00 grep --color=auto libvirtd

Comment 7 Cole Robinson 2013-02-06 20:31:36 UTC
Steve, I think you can fix this locally by

touch /.autorelabel

But we should find a way to not make this fail if running in permissive mode

Comment 8 Daniel Berrangé 2013-03-13 18:08:36 UTC
This series makes libvirt more robust at handling unexpected security labels, which should address this problem


Comment 9 Fedora Update System 2013-04-01 22:05:26 UTC
libvirt- has been submitted as an update for Fedora 18.

Comment 10 Fedora Update System 2013-04-03 04:27:51 UTC
Package libvirt-
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2013-04-11 23:30:48 UTC
libvirt- has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.