Fixed upstream with this patch:

commit 048d13afcc91f4a16a80012aa34b9a024d95368e
Author: Martin Wilck <martin.wilck.com>
Date:   Mon Nov 18 12:35:15 2013 +0100

    transform STP value from "yes/no" to "on/off" in redhat-put.xsl
    
    Some tools (e.g. NetworkManager) use "yes"/"no" in config files
    rather than "on/off". netcf needs to transform this in order to conform
    with the schema.

A fix is available in the following candidate build:

https://brewweb.devel.redhat.com/buildinfo?buildID=334740

Hi Laine, Lubos,

I met some problem when I reproduce this bug.

1. When creating bridge br0 in NetworkManager, an ifcfg-br0 will be created
# cat /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=bridge-br0
STP=yes
BRIDGING_OPTS=priority=128
TYPE=Bridge
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=br0
UUID=5cd60a6a-816b-488b-abd6-2777787ddef9
ONBOOT=yes

then start bridge-br0 from virt-manager, an error will be reported
"Error: Device 'bridge-br0' is waiting for slaves before proceeding with activation."

if add a slave to br0 in virt-manager, choose type is Ethernet, an ifcfg-bridge-slave will be created
# cat /etc/sysconfig/network-scripts/ifcfg-bridge_slave 
HWADDR=10:60:4B:78:2A:74
TYPE=Ethernet
NAME=bridge-slave
UUID=ff64fd7e-a25e-4f19-92e3-41d2c5de952d
ONBOOT=no
BRIDGE=5cd60a6a-816b-488b-abd6-2777787ddef9

then start bridge-br0 from virt-manager, the error is still:
"Error: Device 'bridge-br0' is waiting for slaves before proceeding with activation."

2. If I use nmcli to setup the bridge
The nmcli steps are from https://bugzilla.redhat.com/show_bug.cgi?id=1051401#c3
# nmcli con add type bridge ifname br0
# nmcli con add type bridge-slave ifname eno1 master br0
# nmcli dev disconnect eno1
# nmcli con up bridge-slave-eno1

but the bridge can be listed in virt-manager

could you give some more hints about this reproducing?

Although you may sometimes have success in limited circumstances, netcf and NetworkManager do not work well together, and are not supported together, and we have always said that if you want to use netcf (and the "virsh iface-*" commands, and host interface pieces of virt-manager) you should disable the NetworkManager service and enable the network service instead.

In this case, you've created the bridge with NetworkManager, but then tried to start it with virt-manager/netcf. You should instead create the bridge using virt-manager (or even simpler, the "virsh iface-bridge $physdevname $brname" command).

To give more detail, at least part of the problem is that netcf was written to create and manage bridges with the connection between the bridge and ethernet device indicated with "BRIDGE=$devname" in the ethernet device's config file, but when support for bridges was later added to NetworkManager, it used "BRIDGE=$uuid". netcf starts network devices using /sbin/ifup, and if you directly call /sbin/ifup for a bridge device, it will only attempt to start the bridge itself, but not the attached ethernet devices; recognizing this, if you tell netcf to start a bridge, it will first call /sbin/ifup on any attached ethernet devices, and then ifup the bridge, but NM has put a uuid in the BRIDGE setting rather than a device name, so netcf tries to ifup the uuid, and apparently ifup doesn't recognize uuids.

Again, the solution is to not use NetworkManager, but to either 1) create/edit the ifcfg files manually, 2) use virt-manager, or 3) use the "virsh iface-bridge" command.

This bug is caused by the STP option of the bridge configuration file could be yes/no, but netcf only supports on/off.

The reproducing steps are:
# rpm -q netcf
netcf-0.2.3-7.el7.x86_64

1. create a bridge, for simplest, I used virsh
# virsh iface-bridge eno1 br0 --no-stp --no-start
Created bridge br0 with attached device eno1

2. change ifcfg-br0
# cat /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=dhcp
STP=no

3. start this br0 in virt-manager
# virt-manager --debug
...
2014-03-04 10:57:28,537 (host:1021): Starting interface 'br0'
2014-03-04 10:57:28,539 (asyncjob:190): Creating async job for function cb=<function tmpcb at 0x331af50>
2014-03-04 10:57:29,987 (engine:287): Tick is slow, not running at requested rate.
2014-03-04 10:57:31,335 (host:1108): XML error: bridge interface stp should be on or off got no
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/host.py", line 1106, in interface_selected
    self.populate_interface_state(name)
  File "/usr/share/virt-manager/virtManager/host.py", line 1118, in populate_interface_state
    mac = interface.get_mac()
  File "/usr/share/virt-manager/virtManager/interface.py", line 73, in get_mac
    return self.xpath("/interface/mac/@address")
  File "/usr/share/virt-manager/virtManager/interface.py", line 60, in xpath
    return util.xpath(self.get_xml(inactive=True), *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 100, in get_xml
    return self._XMLDesc(self._inactive_xml_flags)
  File "/usr/share/virt-manager/virtManager/interface.py", line 46, in _XMLDesc
    return self.interface.XMLDesc(flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2417, in XMLDesc
    if ret is None: raise libvirtError ('virInterfaceGetXMLDesc() failed', net=self)
libvirtError: XML error: bridge interface stp should be on or off got no

# virsh iface-unbridge br0
error: XML error: bridge interface stp should be on or off got no


After install latest netcf-0.2.3-8.el7.x86_64 , and restart libvirtd
# rpm -q netcf
netcf-0.2.3-8.el7.x86_64

# virt-manager --debug
...
2014-03-04 11:06:41,978 (host:1021): Starting interface 'br0'
2014-03-04 11:06:41,980 (asyncjob:190): Creating async job for function cb=<function tmpcb at 0x297fd70>
2014-03-04 11:06:43,913 (engine:287): Tick is slow, not running at requested rate.

There is no error happened.

# virsh iface-unbridge br0
Device eno1 un-attached from bridge br0

So that this bug is fixed, and I change the status to VERIFIED.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.