Bug 451784

Summary: libvirt 0.4.3 doesn't always clean up after itself
Product: [Fedora] Fedora Reporter: Chris Lalancette <clalance>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: apevec, berrange
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: 0.4.4-1.fc9 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-01 01:30:17 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 451709    
Bug Blocks:    

Description Chris Lalancette 2008-06-17 08:21:52 EDT
Description of problem:
As a corollary of BZ 451709, when libvirtd fails to start domains because of the
bug there, it also fails to clean up after itself.  In particular, it leaves a
"vnet?" device visible and connected to virbr0, even though there is no domain.
 This further causes problems when rebooting the kernel, since you then get
messages "kernel: waiting for netdev vnet0 to become free" infinitely.  You also
cannot kill the libvirtd daemon.
Comment 1 Chris Lalancette 2008-06-19 05:09:16 EDT
Hm.  Weird.  I can't seem to reproduce the "can't kill libvirtd" problem at the
moment (after a reboot of the host machine).  However, the "doesn't cleanup
vnet?" is still a problem.

Chris Lalancette
Comment 2 Chris Lalancette 2008-06-19 06:08:15 EDT
This one is actually closely related to BZ 451709, which I now have a patch for.
 I'm going to close it as a duplicate.

Chris Lalancette

*** This bug has been marked as a duplicate of 451709 ***
Comment 3 Fedora Update System 2008-06-25 05:27:16 EDT
libvirt-0.4.4-1.fc9 has been submitted as an update for Fedora 9
Comment 4 Fedora Update System 2008-07-01 01:30:10 EDT
libvirt-0.4.4-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.