Bug 1316465
Summary: | active virtual network based on linux bridge will becase inactive after libvirtd restart | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Shanzhi Yu <shyu> |
Component: | libvirt | Assignee: | Laine Stump <laine> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.3 | CC: | dyuan, laine, lizhu, mzhan, rbalakri, yalzhang |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libvirt-1.3.3-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-11-03 18:39:22 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: |
Description
Shanzhi Yu
2016-03-10 10:39:23 UTC
This is fixed upstream: commit 2a537fe187fbca9d95816ffdd9db0327f70ae1be Author: Laine Stump <laine> 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 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. |