Bug 928879
| Summary: | RHEL-6.4: migration is failing: libvirtError: XML error: missing security model when using multiple labels | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Chris Pelland <cpelland> | ||||
| Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | urgent | ||||||
| Version: | 6.4 | CC: | abaron, abienven, acathrow, bazulay, cpelland, dyasny, dyuan, hateya, iheim, italkohe, jdenemar, mjenner, mprivozn, mzhan, pm-eus, rwu, weizhan, whuang, ykaul, zhpeng | ||||
| Target Milestone: | rc | Keywords: | Regression, ZStream | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | libvirt-0.10.2-18.el6_4.3 | Doc Type: | Bug Fix | ||||
| Doc Text: |
When SELinux was disabled on a host, or the qemu driver was configured not to use it, and the domain XML configuration contained an explicit seclabel option, the code parsed the seclabel option, but ignored it later on when it was generating labels on domain start, and created a new and empty seclabel entry [seclabeltype='none'/]. Consequently, a migration between two hosts running Red Hat Enterprise Linux 6.4 failed with the following error message: libvirtError: XML error: missing security model when using multiple labels With this update, if a seclabel entry already exists, a new one is no longer created, and the migration works as expected in the described scenario
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-04-09 10:39:44 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 923946 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Chris Pelland
2013-03-28 16:46:00 UTC
*** Bug 928874 has been marked as a duplicate of this bug. *** *** Bug 928876 has been marked as a duplicate of this bug. *** problem still can be reproduced on qemu-kvm-rhev-0.12.1.2-2.355.el6_4.2.x86_64 libvirt-0.10.2-18.el6_4.3.x86_64 kernel-2.6.32-358.2.1.el6.x86_64 steps are in https://bugzilla.redhat.com/show_bug.cgi?id=923946#c5 Oh, it's actually even worse then what it was before. The domain does not even start, that is, the scenario fails in step 3: 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. managedsave DOM 5. start DOM (In reply to comment #10) > Oh, it's actually even worse then what it was before. The domain does not > even start, that is, the scenario fails in step 3: > I can start the guest in step 3, the situation on my test is just the same as in old version. (In reply to comment #10) > Oh, it's actually even worse then what it was before. The domain does not > even start, that is, the scenario fails in step 3: > > 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. managedsave DOM > 5. start DOM Sorry for not describing so clear, with Jiri's step, in steps 5, guest can be started successfully, but if on step4 instead I restart libvirtd, the domain disappears from virsh list Created attachment 730663 [details]
bug.xml in /var/run/libvirt/qemu/
(In reply to comment #10) > Oh, it's actually even worse then what it was before. The domain does not > even start, that is, the scenario fails in step 3. This is wrong. I forgot to run virsh managedsave-remove DOM after reproducing the issue with the old package. In other words, I can confirm comment 12. The managedsave scenario works (this package fixes it) but the libvirtd restart scenario still does not work. This is not a regression IMO. I've just tested 6.3 and it doesn't work there neither. In fact, I think a bug summary is not corresponding to the description itself. Those are two separate bugs: 1st 6.4.z migration not working, 2nd domain disappearing after libvirtd restart. The first it fixed. The second I can reproduce even on upstream. As I've said in the parent bug and comment 15 the summary does not correspond to the description. I've reported a separate bug 947387 for issue summary describes. Moreover, I am moving this to ON_QA then. According to comment 16 Verify pass on libvirt-0.10.2-18.el6_4.3.x86_64 qemu-kvm-rhev-0.12.1.2-2.355.el6_4.2.x86_64 kernel-2.6.32-358.2.1.el6.x86_64 with steps in comment 10 Start guest on step 5 can succeed 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-0725.html |