Red Hat Bugzilla – Bug 1316465
active virtual network based on linux bridge will becase inactive after libvirtd restart
Last modified: 2017-02-20 14:01:02 EST
Description of problem: active virtual network based on linux bridge will becase inactive after libvirtd restart Version-Release number of selected component (if applicable): libvirt-1.3.2-1.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Prepare a active virtual network based on linux bridge # virsh net-define /dev/stdin <<EOF <network> <name>net-bridge</name> <uuid>f0857c0e-b9b5-41e7-9f3f-0d03b0cefa11</uuid> <forward dev='br0' mode='bridge'> <interface dev='br0'/> </forward> </network> EOF # virsh net-start net-bridge Network net-bridge started # virsh net-list Name State Autostart Persistent ---------------------------------------------------------- net-bridge active no yes 2. Restart libvirtd daemon # systemctl restart libvirtd.service 3. Check virtual network status # virsh net-list Name State Autostart Persistent ---------------------------------------------------------- # virsh net-list --inactive |grep net-bridge net-bridge inactive no yes Actual results: Expected results: Additional info:
This is fixed upstream: commit 2a537fe187fbca9d95816ffdd9db0327f70ae1be Author: Laine Stump <laine@laine.org> Date: Fri Mar 11 10:59:19 2016 -0500 network: differentiate macvtap/bridge from host-bridge based networks
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
verified on libvirt-1.3.3-1.el7.x86_64, the result is as expected. create a linux bridge, and then define and start a network with mode=bridge. # virsh net-dumpxml net-bridge <network> <name>net-bridge</name> <uuid>f0857c0e-b9b5-41e7-9f3f-0d03b0cefa11</uuid> <forward dev='br0' mode='bridge'> <interface dev='br0'/> </forward> </network> # virsh net-list --all Name State Autostart Persistent ---------------------------------------------------------- default active no yes net-bridge active no yes # systemctl restart network.service # virsh net-list --all Name State Autostart Persistent ---------------------------------------------------------- default active no yes net-bridge active no yes Try macvtap, hostdev, the result is as expected. After restart the libvirtd service, the network status keeps the same.
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. https://rhn.redhat.com/errata/RHSA-2016-2577.html
Hi Laine, This is a common scenario, user may restart libvirtd service or udpate the libvirt packages. So if we need to backport it to RHEL6? (may be rhel6.10, 6.11..). Currently on rhel6.9, libvirt-0.10.2-62.el6.x86_64, bridge, macvtap, hostdev network will stay inactive after libvirtd restart even they were active before the start.
commit 2a537fe187fbca9d95816ffdd9db0327f70ae1be fixes a bug that was introduced in commit b61db335 (first in release 1.2.14), so it wouldn't be applicable to the libvirt 0.10.2 that's in RHEL6. The failure to maintain the status of bridge, macvtap, and hostdev networks when libvirtd is restarted in RHEL6 is caused by more basic deficiencies in the older code, and requires a much larger set of patches that would not be easily backported to 0.10.2, and anyway two mitigating factors make it less important for the networks to have their active status maintained: 1) in libvirt 0.10.2 bridge, macvtap, and hostdev networks can still be used when they are inactive. 2) if a network is marked as autostart, it will be re-marked as active when libvirtd is restarted (and all devices used by active guests will be re-marked as in-use in the network) Between those two items, the impact of the bug becomes almost 0, so in my opinion it's unnecessary (and even dangerous, since it would be very likely to introduce new regressions) to fix this behavior in RHEL6. This is why we made the decision several years ago to only fix it upstream, and not attempt a backport to RHEL6. If you see a practical problem caused by this that can't be overcome by simply marking the network as autostart, we can revisit the issue.