Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
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
(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.
Comment 15Michal Privoznik
2013-04-02 09:58:35 UTC
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.
Comment 16Michal Privoznik
2013-04-02 10:14:35 UTC
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