Red Hat Bugzilla – Bug 947387
Running domain may disappear after libvirtd is restarted when selinux security driver is disabled
Last modified: 2014-06-09 07:18:52 EDT
Description of problem: If a domain with selinux seclabel is started on a host with selinux disabled, it will disapper after libvirtd service restart. Version-Release number of selected component (if applicable): libvirt.x86_64 0:0.10.2-18.el6_4.3 How reproducible: 100% Steps to Reproduce: 1. set security_driver = "none" in /etc/libvirt/qemu.conf (or alternatively disable SELinux on the host) 2. restart libvirtd service (or the host in case the alternative route in step 1 was chosen) 3. start a domain which contains <seclabel type='dynamic' model='selinux' relabel='yes'/> in its XML configuration 4. restart libvirtd 5. domain is lost (or in shutoff state in case of persistent domain) Actual results: Domain disappers from 'virsh list' (or is shown as shut off) Expected results: Domain does not disappar (or is shown as running). Additional info: This is the behaviour that has been around for ages. However, we'd interchanged this for Bug 923946 which reports slightly different problem.
Moving to POST: commit 8d68cbeaa8a64759323da1d64526e2a941eb93e1 Author: Michal Privoznik <mprivozn@redhat.com> AuthorDate: Tue Apr 2 17:49:34 2013 +0200 Commit: Michal Privoznik <mprivozn@redhat.com> CommitDate: Wed Apr 3 10:19:46 2013 +0200 sec_manager: Refuse to start domain with unsupported seclabel https://bugzilla.redhat.com/show_bug.cgi?id=947387 If a user configures a domain to use a seclabel of a specific type, but the appropriate driver is not accessible, we should refuse to start the domain. For instance, if user requires selinux, but it is either non present in the system, or is just disabled, we should not start the domain. Moreover, since we are touching only those labels we have a security driver for, the other labels may confuse libvirt when reconnecting to a domain on libvirtd restart. In our selinux example, when starting up a domain, missing security label is okay, as we auto-generate one. But later, when libvirt is re-connecting to a live qemu instance, we parse a state XML, where security label is required and it is an error if missing: error : virSecurityLabelDefParseXML:3228 : XML error: security label is missing This results in a qemu process left behind without any libvirt control. v1.0.4-22-g8d68cbe
Huh, for some reason this bug was in POST, but the patch hasn't been backported. So here's the patch: http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-July/msg00332.html
# rpm -q libvirt libvirt-0.10.2-20.el6.x86_64 Following the reproduce steps in comment 0 when start the guest, get expect error # virsh start virtlab_test error: Failed to start domain virtlab_test error: unsupported configuration: Unable to find security driver for label selinux So this bug can VERIFIED. BTW, if remove the configuration: security_driver = "none", restart libvirtd, when start the domain, libvirtd will crash, there's a new bug 984793 to track this problem.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1581.html