Bug 238492 - virbr0 disappears/reappears upon service libvirtd restart
Summary: virbr0 disappears/reappears upon service libvirtd restart
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Berrange
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-30 20:54 UTC by Warren Togami
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version: libvirt-0.2.2-3.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-04 16:29:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Warren Togami 2007-04-30 20:54:51 UTC
[root@newcaprica tmp]# rpm -q libvirt
libvirt-0.2.2-2.fc7
[root@newcaprica tmp]# arch
x86_64
[root@newcaprica tmp]# ifconfig virbr0
virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:9064 (8.8 KiB)

[root@newcaprica tmp]# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]
[root@newcaprica tmp]# ifconfig virbr0
virbr0: error fetching interface information: Device not found
[root@newcaprica tmp]# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]
[root@newcaprica tmp]# ifconfig virbr0
virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:3417 (3.3 KiB)

Comment 1 Daniel Berrange 2007-04-30 21:12:55 UTC
Sounds very much like a race condition between tearing down & recreating the
bridge device. We do

int
brDeleteBridge(brControl *ctl,
               const char *name)
{
    if (!ctl || !ctl->fd || !name)
        return EINVAL;

    return ioctl(ctl->fd, SIOCBRDELBR, name) == 0 ? 0 : errno;
}


And I expect that ioctl completes  asychronously - ie returns before the bridge
has actually been torn down. So if libvirt starts back up again too quickly we
could find ourselves trying to re-create the bridge before it has gone away in
the first place.

Could either sleep in the init script, or better, actually block pending
completion of teardown in brDeleteBridge, since the same thing could occurr if
someone did   virsh net-destroy default && virsh net-start default

Comment 2 Mark McLoughlin 2007-05-02 16:43:35 UTC
Btw, the error message from /var/log/messages is:

  libvirt-qemud: Failed to autostart network 'default': cannot create bridge
'virbr0' : File exists

From what I can see, the ioctl is synchronous - I can't reproduce the EEXIST
with a simple test case.

What actually seems to be the problem is that, with restart, the initscript just
does a kill -TERM and then immediately starts a new instance of the daemon. At
that point the old daemon hasn't actually deleted the bridge.

The fix is simple:

-    killproc $PROCESS -TERM
+    killproc $PROCESS

without a kill level arg, killproc will check to see if the process has died and
block for a few seconds before sending it a KILL signal.

Seems to fix the problem for me.

Comment 3 Mark McLoughlin 2007-05-03 09:03:21 UTC
Dan is going to push a libvirt build with this:

  http://www.redhat.com/archives/libvir-list/2007-May/msg00026.html


Comment 4 Mark McLoughlin 2007-05-04 16:29:27 UTC
Fixed in libvirt-0.2.2-3.fc7


Note You need to log in before you can comment on or make changes to this bug.