Bug 984793
Summary: | libvirtd crashed when start a guest with <seclabel> element in xml | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | EricLee <bili> | ||||||||||||
Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> | ||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||||||
Severity: | urgent | Docs Contact: | |||||||||||||
Priority: | urgent | ||||||||||||||
Version: | 6.5 | CC: | acathrow, ajia, cwei, dyuan, gsun, honzhang, jiahu, jmiao, mprivozn, mzhan, shyu, xuzhang, ydu, zhwang | ||||||||||||
Target Milestone: | rc | ||||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | x86_64 | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | libvirt-0.10.2-21.el6 | Doc Type: | Bug Fix | ||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2013-11-21 09:05:17 UTC | Type: | Bug | ||||||||||||
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: | |||||||||||||||
Bug Blocks: | 920205 | ||||||||||||||
Attachments: |
|
Description
EricLee
2013-07-16 04:18:01 UTC
Hi all, This bug should be a regression as libvirt-0.10.2-19.el6 can not reproduce, can I set the regression/block keywords? And for libvirtd.log, please see next comment. Thanks, EricLee Created attachment 774006 [details]
libvirtd crash log
I haven't found the issue on libvirt upstream, maybe, some patches need to been backported into libvirt rhel. In addition, I think this question is introduced by memory leaks. ==21463== 1,220 (288 direct, 932 indirect) bytes in 1 blocks are definitely lost in loss record 95 of 105 ==21463== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==21463== by 0x4C83C9B: virAllocN (memory.c:128) ==21463== by 0x4C96AAB: virObjectNew (virobject.c:100) ==21463== by 0x4D0171E: virGetConnect (datatypes.c:109) ==21463== by 0x4D1AE25: do_open (libvirt.c:1078) ==21463== by 0x4D1C07A: virConnectOpenAuth (libvirt.c:1407) ==21463== by 0x40C6F5: vshReconnect (virsh.c:340) ==21463== by 0x40D28F: vshCommandRun (virsh.c:1645) ==21463== by 0x410B4A: main (virsh.c:3093) (In reply to Alex Jia from comment #4) > I haven't found the issue on libvirt upstream, maybe, some patches need to > been backported into libvirt rhel. Can successfully start a guest. > > In addition, I think this question is introduced by memory leaks. > > ==21463== 1,220 (288 direct, 932 indirect) bytes in 1 blocks are definitely > lost in loss record 95 of 105 > ==21463== at 0x4A04A28: calloc (vg_replace_malloc.c:467) > ==21463== by 0x4C83C9B: virAllocN (memory.c:128) > ==21463== by 0x4C96AAB: virObjectNew (virobject.c:100) > ==21463== by 0x4D0171E: virGetConnect (datatypes.c:109) > ==21463== by 0x4D1AE25: do_open (libvirt.c:1078) > ==21463== by 0x4D1C07A: virConnectOpenAuth (libvirt.c:1407) > ==21463== by 0x40C6F5: vshReconnect (virsh.c:340) > ==21463== by 0x40D28F: vshCommandRun (virsh.c:1645) > ==21463== by 0x410B4A: main (virsh.c:3093) It should be another question, the libvirt raises memory leaks with error path (after the libvirtd crashing ). Not sure whether need to backport the following patches into libvirt rhel: commit 2ce63c161111c6d813130f850639d1548d80c3fe Author: Peter Krempa <pkrempa> Date: Tue Jul 2 18:34:58 2013 +0200 selinux: Always generate imagelabel The imagelabel SELinux label was only generated when relabeling was enabled. This prohibited labeling of files created by libvirt that need to be labeled even if relabeling is turned off. The only codepath this change has direct impact on is labeling of FDs passed to qemu which is always safe in current state. commit 48b49a631a0e6ab58376325c8301d5e52152a221 Author: Daniel P. Berrange <berrange> Date: Wed Feb 6 12:40:41 2013 +0000 Serialize execution of security manager APIs Add locking to virSecurityManagerXXX APIs, so that use of the security drivers is internally serialized. This avoids the need to rely on the global driver locks to achieve serialization Signed-off-by: Daniel P. Berrange <berrange> I am curious about the patch : commit 8d68cbeaa8a64759323da1d64526e2a941eb93e1 Author: Michal Privoznik <mprivozn> AuthorDate: Tue Apr 2 17:49:34 2013 +0200 Commit: Michal Privoznik <mprivozn> CommitDate: Wed Apr 3 10:19:46 2013 +0200 @@ -437,6 +437,19 @@ int virSecurityManagerGenLabel(virSecurityManagerPtr mgr, return ret; virObjectLock(mgr); + for (i = 0; vm->nseclabels; i++) { Look here, the condition is vm->nseclabels. It is no related to loop variable i. That means if vm->nseclabels is true, the loop will not stop. I guess it should be "for (i = 0; i < vm->nseclabels; i++)" either "for (i = 0; vm->seclabels[i]; i++)" + for (j = 0; sec_managers[j]; j++) + if (STREQ(vm->seclabels[i]->model, sec_managers[j]->drv->name)) + break; + + if (!sec_managers[j]) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Unable to find security driver for label %s"), + vm->seclabels[i]->model); + goto cleanup; + } + } + And I will test it. After I change the condition, it is ok to start a guest with <seclabel type='dynamic' model='selinux' relabel='yes'/>. (In reply to Jincheng Miao from comment #7) > I am curious about the patch : > > commit 8d68cbeaa8a64759323da1d64526e2a941eb93e1 > Author: Michal Privoznik <mprivozn> > AuthorDate: Tue Apr 2 17:49:34 2013 +0200 > Commit: Michal Privoznik <mprivozn> > CommitDate: Wed Apr 3 10:19:46 2013 +0200 > It seems it's not a root reason, with same patch, the libvirt upstream is fine. So we need to backport this commit: commit ea151935bb5cfacc0290f60960f8d515ca52ab29 Author: Guido Günther <agx> AuthorDate: Wed Apr 3 22:08:58 2013 +0200 Commit: Guido Günther <agx> CommitDate: Wed Apr 3 22:57:31 2013 +0200 security_manager: fix comparison otherwise we crash later on if we don't find a match like: #0 0xb72c2b4f in virSecurityManagerGenLabel (mgr=0xb8e42d20, vm=0xb8ef40c0) at security/security_manager.c:424 #1 0xb18811f3 in qemuProcessStart (conn=conn@entry=0xb8eed880, driver=driver@entry=0xb8e3b1e0, vm=vm@entry=0xb8ef58f0, migrateFrom=migrateFrom@entry=0xb18f6088 "stdio", stdin_fd=18, stdin_path=stdin_path@entry=0xb8ea7798 "/var/lib/jenkins/jobs/libvirt-tck-build/workspace/tck.img", snapshot=snapshot@entry=0x0, vmop=vmop@entry=VIR_NETDEV_VPORT_PROFILE_OP_RESTORE, flags=flags@entry=2) at qemu/qemu_process.c:3364 #2 0xb18d6cb2 in qemuDomainSaveImageStartVM (conn=conn@entry=0xb8eed880, driver=driver@entry=0xb8e3b1e0, vm=0xb8ef58f0, fd=fd@entry=0xb6bf3f98, header=header@entry=0xb6bf3fa0, path=path@entry=0xb8ea7798 "/var/lib/jenkins/jobs/libvirt-tck-build/workspace/tck.img", start_paused=start_paused@entry=false) at qemu/qemu_driver.c:4843 #3 0xb18d7eeb in qemuDomainRestoreFlags (conn=conn@entry=0xb8eed880, path=path@entry=0xb8ea7798 "/var/lib/jenkins/jobs/libvirt-tck-build/workspace/tck.img", dxml=dxml@entry=0x0, flags=flags@entry=0) at qemu/qemu_driver.c:4962 #4 0xb18d8123 in qemuDomainRestore (conn=0xb8eed880, path=0xb8ea7798 "/var/lib/jenkins/jobs/libvirt-tck-build/workspace/tck.img") at qemu/qemu_driver.c:4987 #5 0xb718d186 in virDomainRestore (conn=0xb8eed880, from=0xb8ea87d8 "/var/lib/jenkins/jobs/libvirt-tck-build/workspace/tck.img") at libvirt.c:2768 #6 0xb7736363 in remoteDispatchDomainRestore (args=<optimized out>, rerr=0xb6bf41f0, client=0xb8eedaf0, server=<optimized out>, msg=<optimized out>) at remote_dispatch.h:4679 #7 remoteDispatchDomainRestoreHelper (server=0xb8e1a3e0, client=0xb8eedaf0, msg=0xb8ee72c8, rerr=0xb6bf41f0, args=0xb8ea8968, ret=0xb8ef5330) at remote_dispatch.h:4661 #8 0xb720db01 in virNetServerProgramDispatchCall (msg=0xb8ee72c8, client=0xb8eedaf0, server=0xb8e1a3e0, prog=0xb8e216b0) at rpc/virnetserverprogram.c:439 #9 virNetServerProgramDispatch (prog=0xb8e216b0, server=server@entry=0xb8e1a3e0, client=0xb8eedaf0, msg=0xb8ee72c8) at rpc/virnetserverprogram.c:305 #10 0xb7206e97 in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0xb8e1a3e0) at rpc/virnetserver.c:162 #11 virNetServerHandleJob (jobOpaque=0xb8ea7720, opaque=0xb8e1a3e0) at rpc/virnetserver.c:183 #12 0xb70f9f78 in virThreadPoolWorker (opaque=opaque@entry=0xb8e1a540) at util/virthreadpool.c:144 #13 0xb70f94a5 in virThreadHelper (data=0xb8e0e558) at util/virthreadpthread.c:161 #14 0xb705d954 in start_thread (arg=0xb6bf4b70) at pthread_create.c:304 #15 0xb6fd595e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 This unbreaks libvirt-tck's domain/100-transient-save-restore.t with qemu:///session and selinux compiled in but disabled. Introduced by 8d68cbeaa8a64759323da1d64526e2a941eb93e1 hi, I met one issue with build libvirt-0.10.2-20.el6.x86_64, the libvirtd log info and backtrace info seems same like this bug. The steps is: 1. save one running VM. # virsh save a a.save Domain a saved to a.save 2. then restore the VM with that save file in step1. # virsh restore a.save error: Failed to restore domain from a.save error: End of file while reading data: Input/output error error: One or more references were leaked after disconnect from the hypervisor error: Failed to reconnect to the hypervisor As you can see the libvirtd is crashed while restore the saved file. I attached the libvirtd log and backtrace info for your reference, it seems like that the 2 issues are caused by same reason. Created attachment 774165 [details]
backtrace while restore saved file
Created attachment 774166 [details]
libvirtd log while restoring saved file
Created attachment 774628 [details]
libvirtd_rhevm_log
guest migration failed
Created attachment 774629 [details]
vdsm_rhevm_log
guest migration failed
I met migration fail on libvirt-0.10.2-20.el6.x86_64 in rhevm,so can not verify this bug, after checking the logs, maybe this migration fail issue is same as bug 984793, https://bugzilla.redhat.com/show_bug.cgi?id=984793#c12 Hosts packages version: libvirt-0.10.2-20.el6.x86_64 libvirt-client-0.10.2-20.el6.x86_64 libvirt-debuginfo-0.10.2-20.el6.x86_64 libvirt-devel-0.10.2-20.el6.x86_64 libvirt-lock-sanlock-0.10.2-20.el6.x86_64 libvirt-python-0.10.2-20.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.355.el6_4.6.x86_64 qemu-kvm-rhev-debuginfo-0.12.1.2-2.355.el6_4.2.x86_64 qemu-kvm-rhev-tools-0.12.1.2-2.355.el6_4.2.x86_64 spice-client-0.8.2-15.el6.x86_64 spice-glib-0.14-7.el6.x86_64 spice-gtk-0.14-7.el6.x86_64 spice-gtk-python-0.14-7.el6.x86_64 spice-server-0.12.0-12.el6.x86_64 spice-vdagent-0.12.0-4.el6.x86_64 vdsm-4.10.2-23.0.el6ev.x86_64 vdsm-cli-4.10.2-23.0.el6ev.noarch vdsm-python-4.10.2-23.0.el6ev.x86_64 vdsm-xmlrpc-4.10.2-23.0.el6ev.noarch Also, I attached the logs, libvirtd_rhevm_log and vdsm_rhevm_log. Please ignore comment 18,that's wrong comment. Also, ignore comment 16,17. As for comment 12, the root reason is caused by seclabel after debug. Here is the detail description about comment 12. 1. define and start one guest without seclabel. 2. then we can start and destroy the guest successfully, no libvirtd crash. Check the dumpxml, then find: guest is shutoff status: didn't contains any seclabel. guest is running status: libvirtd will add the seclabel automatically. 3. save the guest, after save, the guest is in shutoff status. saved file contains the running guest status, so the saved file contans seclabel info. 4. restore the guest, libvirtd crashed. 5. while resotre the guest, if adding option "--xml", add dumpxml file which didn't contain seclabel, the guest will be restored and libvirtd will not crashed. From the step 4 and step 5, we can see, the restore issue is also caused by seclabel. The same reason with this bug. Verify this bug with libvirt-0.10.2-21.el6.x86_64. 1. Prepare a guest with <seclabel> element: ... <seclabel type='dynamic' model='selinux' relabel='yes'/> ... 2. Start the guest # virsh start test Domain test started 3. Check the guest xml # virsh dumpxml test |grep seclabel -A 3 <seclabel type='dynamic' model='selinux' relabel='yes'> <label>system_u:system_r:svirt_t:s0:c73,c933</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c73,c933</imagelabel> </seclabel> </domain> 4. Save and restore the guest # virsh save test /tmp/test.save Domain test saved to /tmp/test.save # virsh restore /tmp/test.save Domain restored from /tmp/test.save # virsh domstate test running 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 |