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.