Bug 766308
| Summary: | libvirtd does not close all fds opened by virt-install | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Sadique Puthen <sputhenp> | ||||||||||
| Component: | libvirt | Assignee: | Peter Krempa <pkrempa> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 6.2 | CC: | acathrow, ajia, dallan, mzhan, rwu, ydu, zhpeng | ||||||||||
| Target Milestone: | rc | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | libvirt-0.9.9-1.el6 | Doc Type: | Bug Fix | ||||||||||
| Doc Text: |
No Documentation needed
|
Story Points: | --- | ||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2012-06-20 06:38:29 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: | |||||||||||||
| Attachments: |
|
||||||||||||
(In reply to comment #0) > I have done multiple installations to verify that the one extra fd is > associated with virt-install and not by libvirtd for other purposes. Can you track down the problem further? Ideally, I would think that this is the kind of BZ for which SEG could submit a patch. It looks like a simple resource leak. (In reply to comment #0) > Description of problem: > > libvirtd does not close all fds opened to install guests by virt-install after > virt-install finished installing the guest. > > Version-Release number of selected component (if applicable): > > libvirt-0.9.4-12.el6.x86_64 > BTW, it's okay for libvirt-0.9.8-1.el6.x86_64, I haven't found fds leak after virt-install completing installation, so it should be also okay on upstream, although I can't confirm which commit fixed this issue. Created attachment 546578 [details]
before installation
Created attachment 546579 [details]
installation
Created attachment 546580 [details]
after installation
Created attachment 546585 [details]
after restart libvirtd
I can reproduce this with libvirt-0.9.4-23.el6.x86_64. And can't reproduce this with libvirt-0.9.8-1.el6.x86_64. Updated 4 logs of comment 0 from "before installation" to "restart libvirtd" of comment 0. It seems some patch hasn't been backported into libvirt rpm package of RHEL:
commit 7ea2ef4ce82be9574b4e1fb2a90f2f2c8dc84172
Author: Daniel P. Berrange <berrange>
Date: Tue Jul 19 14:11:33 2011 +0100
Use a virFreeCallback on virNetSocket to ensure safe release
When unregistering an I/O callback from a virNetSocket object,
there is still a chance that an event may come in on the callback.
In this case it is possible that the virNetSocket might have been
freed already. Make use of a virFreeCallback when registering
the I/O callbacks and hold a reference for the entire time the
callback is set.
* src/rpc/virnetsocket.c: Register a free function for the
file handle watch
* src/rpc/virnetsocket.h, src/rpc/virnetserverservice.c,
src/rpc/virnetserverclient.c, src/rpc/virnetclient.c: Add
a free function for the socket I/O watches
If so, maybe, should open the bug in 6.2.z, then cherry-pick the patch.
(In reply to comment #7) > I can reproduce this with libvirt-0.9.4-23.el6.x86_64. > And can't reproduce this with libvirt-0.9.8-1.el6.x86_64. > > Updated 4 logs of comment 0 from "before installation" to "restart libvirtd" of > comment 0. Moving to POST Test this bug with libvirt-0.9.9-1.el6.x86_64.
1. Before starting installation:
# lsof | grep libvirt | wc
171 1542 17900
2. During installation:
# lsof | grep libvirt | wc
185 1676 19793
3. After installation:
# lsof | grep libvirt | wc
171 1542 17900
All fds opened by virt-install are closed, so move bug to VERIFIED.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
No Documentation needed
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/RHSA-2012-0748.html |
Description of problem: libvirtd does not close all fds opened to install guests by virt-install after virt-install finished installing the guest. Version-Release number of selected component (if applicable): libvirt-0.9.4-12.el6.x86_64 How reproducible: Always. Steps to Reproduce: Fds opened by libvirted before starting installation: # lsof | grep libvirt | wc 102 922 10980 During installation. # lsof | grep libvirt | wc 117 1067 12790 Installation is done using the below command. # virt-install -r 1000 -n sadique-test5 --disk path=/home/images/sadique-test5.img,format=raw,bus=virtio,size=10 --network bridge=br1,model=virtio --os-type=linux --os-variant=rhel6 --vcpus=2,maxvcpus=4 --cdrom=/tmp/rhel-server-5.4-x86_64-dvd.iso After the installation. (we can see that 1 fd is not closed) # lsof | grep libvirt | wc 103 933 11086 After restarting libvirtd immediately. # service libvirtd restart Stopping libvirtd daemon: [ OK ] Starting libvirtd daemon: [ OK ] [root@dhcp210-207 ~]# lsof | grep libvirt | wc 102 922 10980 I have done multiple installations to verify that the one extra fd is associated with virt-install and not by libvirtd for other purposes.