Doesn't reproduce for me in my quick test, can you reproduce with virt-manager --debug and post the output here?

Created attachment 848091 [details]
'virt-manager --debug' output while creating the bridge

I get the exact same error. I remember having it with F19 as well.
One note about my configuration : I already have VMs configured with the missing bridge that I try to create. Maybe it's a cause of the problem.

See the attachment produced with virt-manager --debug

Some extra info :
I looked at the source line that crashed, and it made me think of something. The problem occured while my network configuration was not perfect : I tried adding bridges with the network manager applet, then deleted them (because they failed).
However, it appears that NetworkManager keeped track of those interfaces.
The applet showed nothing, while, in 2 subsequent tries, nmcli gave :
# nmcli con show conf
NAME                UUID                                  TYPE            TIMESTAMP-REAL                  
bridge-slave-p4p1   cf59a901-3efb-4cd2-94a6-c81d1db15be1  802-3-ethernet  never                           
Esclave br0 1       3d6369bf-a016-4362-abb6-ce553bcb74bb  802-3-ethernet  never                           
Wired connection 1  8b510c02-85ff-4c53-8909-5779db1dcdf9  802-3-ethernet  Fri 10 Jan 2014 09:29:50 AM CET 
Esclave bridge0 1   fce70967-fc56-4125-9a88-3911532a3b46  802-3-ethernet  never                           
bridge-slave-eth1   d76b3860-ccd0-497e-b6cc-588153396acc  802-3-ethernet  never 

And in another attempt :

# nmcli con show conf
NAME                UUID                                  TYPE            TIMESTAMP-REAL                  
Wired connection 1  8b510c02-85ff-4c53-8909-5779db1dcdf9  802-3-ethernet  Fri 10 Jan 2014 09:49:42 AM CET 
Esclave br0 1       0b8875b9-51c5-49fb-8c8d-9084d3af3a91  802-3-ethernet  never                           
bridge-slave-p4p1   44cea78d-b3f6-4657-a7e8-60ce0226a29e  802-3-ethernet  never                          


I manually deleted all those erroneous configurations (nmcli con delete ...), and then libvirt was OK creating the interfaces.

According to the "erroneous" python code, it tries to retreive the XML for the misconfigured interfaces : since they do not appear in libvirt (god knows why...), there is no valid XML...
I think, however bad the configuration is, the missing interfaces should be ignored. Maybe it would be wise to show a warning to the user, but let him configure the bridge.

I hope this will help fix the bug!

Sorry for adding the informations in several messages, but I try to commit before forgetting... :-)
apparrently, the problems is not related to any erroneous NetworkManager configuration.
The problem is on lines 502/508 of createinterface.py :
for phys in self.conn.get_nodedevs("net"): --> returns lo and p4p1
for name in self.conn.list_interface_names(): --> returns lo only

since in the first loop, row_dict gets initialized with this :
row_dict[phys.interface] = [phys.interface,
                                        False, False, phys.interface,
                                        "ethernet", False, True, None,
                                        phys.address]

phys.interface stays as the first value (corresponding to key 0=INTERFACE_ROW_KEY, which should be replaced with "key = iface.get_backend()" in the second loop).

As I understand it, I should first create the ethernet interface in libvirt.
However, when I try to do so, I get an error : "the name "p4p1" is already in use by another interface"

I tried another thing : I commented out lines 155/156 of /usr/share/virt-manager/virtinst/interface.py , in order to be able to create "p4p1" as ethernet interface.
I then created the bridge, almost successfuly :
-at first attempt, I got the following :
 DEBUG (asyncjob:194) Creating async job for function cb=<bound method vmmCreateInterface.do_install of <vmmCreateInterface object at 0x7f9ddc06b5f0 (virtManager+createinterface+vmmCreateInterface at 0x296aac0)>>
[ven., 10 janv. 2014 10:28:34 virt-manager 13104] DEBUG (interface:243) Creating interface 'br1' with xml:
<interface type="bridge" name="br1">
  <bridge stp="on" delay="0.0">
    <interface type="ethernet" name="p4p1">
      <mac address="14:da:e9:03:ee:af"/>
      <protocol family="ipv4">
        <ip address="192.168.1.128" prefix="24"/>
      </protocol>
      <protocol family="ipv6">
        <ip address="fe80::16da:e9ff:fe03:eeaf" prefix="64"/>
      </protocol>
    </interface>
  </bridge>
  <start mode="onboot"/>
  <protocol family="ipv4">
    <ip address="192.168.1.128"/>
    <route gateway="192.168.1.1"/>
  </protocol>
</interface>

[ven., 10 janv. 2014 10:28:37 virt-manager 13104] DEBUG (error:84) error dialog message:
summary=Erreur lors de la création de l'interface : « Could not create interface: internal error: failed to create (start) interface br1: unspecified error - interface br1 failed to become active - possible disconnected cable. »



I then checked, and, strangely, the bridge had still be created :
# brctl show
bridge name	bridge id		STP enabled	interfaces
br1		8000.14dae903eeaf	yes		p4p1

Thus, I tried to validate the page a second time, and this time it worked : the bridge was successfully created!

I will now see if it survives a reboot...

I was able to reproduce the same problem here.  The reason seems to be the one described in comment #4, some net devices don't get updated by the second loop so their INTERFACE_ROW_KEY remains a string value.

Fixed upstream now:

commit 077eac8c1d1359dbedb678346c84c0bc730ff021
Author: Cole Robinson <crobinso>
Date:   Fri Jan 17 20:25:08 2014 -0500

    createinterface: Fix creating bridge with unconfigured interface (bz 1048351

Any chance that this will arrive in virt-preview soon?

Thanks!

Frederic.

I'll be doing a new build within the next few weeks.

Also, I should have said, thank you Frederic for doing all that work to track down the bug, certainly made life easier for me :)

If you don't want to wait for a build, running virt-manager from git is quite easy:

git clone git://git.fedorahosted.org/virt-manager.git
cd virt-manager
./virt-manager

should be all that's needed

>Also, I should have said, thank you Frederic for doing all that work to track 
>down the bug, certainly made life easier for me :)

It's too much of a constrain for me to commit to a specific project on a long-term basis, so I'm trying to do "my part of the job" when I hit bugs :-)

>git clone git://git.fedorahosted.org/virt-manager.git
>cd virt-manager
>./virt-manager

I forgot the magic world of interpreted languages :-)
I've tested it, and it almost works : comment #5 is still valid (had to create the bridge twice)
Should I open a separate bug?

Frédéric.

(In reply to Frederic Grelot from comment #11)

> I've tested it, and it almost works : comment #5 is still valid (had to
> create the bridge twice)
> Should I open a separate bug?
> 

Please file a separate bug: probably a libvirt or netcf issue, but just file it against virt-manager and we can go from there. And please provide the virt-manager --debug output when reproducing.

Well, actually I already filed a bug about a similar problem, and I think it's the same one :
https://bugzilla.redhat.com/show_bug.cgi?id=1051401
This one is about NetworkManager, but the problem is identical. Nobody reacted on it thought.

Frederic.

I confirm this is broken in my setup as well.

This is still broken in git:

Note: This only works until you reboot machine... then NM complains and nothing gets configured again:

Adding: 
NM_CONTROLLED=no

to the generated ifcfg files will work, I disabled NetworkManager for now.

(since this falls back to /etc/init.d/network that systemd will launch)

Shawn, the original report is still broken in git, or the bridge issue reported in Comment #13? NM_CONTROLLED=no should have no bearing on the initial bug report.

We can say the parse issue is fixed. I will spin off another bug wrt to the other issue.

Created attachment 862563 [details]
Dialog GUI when creating a bridge

Created attachment 862564 [details]
--debug output when there are no interfaces listed for attaching to the bridge

I have the same problem. However, when I try the version from git://git.fedorahosted.org/virt-manager.git it does not work for me.

When I get to the point where I am adding the bridge and it is in "Step 2 of 2" it lists no interfaces for me to attach to the bridge. I have attached a PNG of the dialog screen and the debug output.

Here;s the traceback:

[Wed, 12 Feb 2014 14:34:51 virt-manager 7742] DEBUG (createinterface:123) Showing new interface wizard
[Wed, 12 Feb 2014 14:34:52 virt-manager 7742] DEBUG (cli:182) Uncaught exception:
Traceback (most recent call last):
  File "/home/rad/virt-manager/virtManager/createinterface.py", line 880, in page_changed
    self.populate_details_page()
  File "/home/rad/virt-manager/virtManager/createinterface.py", line 403, in populate_details_page
    self.populate_interface_list(itype)
  File "/home/rad/virt-manager/virtManager/createinterface.py", line 551, in populate_interface_list
    key.name = name
  File "/home/rad/virt-manager/virtinst/xmlbuilder.py", line 617, in setter
    self._validate_cb(xmlbuilder, val)
  File "/home/rad/virt-manager/virtinst/interface.py", line 156, in _validate_name
    name)
ValueError: Name 'wlp2s0' already in use by another interface.

Indeed that looks like an upstream issue, I'll take a look

Bob, can you file a new virt-manager bug for upstream: Community->Virtualization Tools->virt-manager

At the new bug report, please add your virt-manager.log from above, and additionally provide:

sudo virsh iface-list --all
sudo virsh iface-dumpxml $iface   (for ever interface name listed with list --all)

Cole, What should I list as the version?

Doesn't matter, I don't pay attention to that field.

virt-manager-1.0.0-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/virt-manager-1.0.0-1.fc20

virt-manager-1.0.0-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/virt-manager-1.0.0-2.fc20

Package virt-manager-1.0.0-2.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing virt-manager-1.0.0-2.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-2789/virt-manager-1.0.0-2.fc20
then log in and leave karma (feedback).

(In reply to Fedora Update System from comment #28)
> Package virt-manager-1.0.0-2.fc20:
> * should fix your issue,
> * was pushed to the Fedora 20 testing repository,
> * should be available at your local mirror within two days.
> Update it with:
> # su -c 'yum update --enablerepo=updates-testing virt-manager-1.0.0-2.fc20'
> as soon as you are able to.
> Please go to the following url:
> https://admin.fedoraproject.org/updates/FEDORA-2014-2789/virt-manager-1.0.0-
> 2.fc20
> then log in and leave karma (feedback).

Installed the update, now it only shows lo interface.

(In reply to Mustafa from comment #29)
> (In reply to Fedora Update System from comment #28)
> > Package virt-manager-1.0.0-2.fc20:
> > * should fix your issue,
> > * was pushed to the Fedora 20 testing repository,
> > * should be available at your local mirror within two days.
> > Update it with:
> > # su -c 'yum update --enablerepo=updates-testing virt-manager-1.0.0-2.fc20'
> > as soon as you are able to.
> > Please go to the following url:
> > https://admin.fedoraproject.org/updates/FEDORA-2014-2789/virt-manager-1.0.0-
> > 2.fc20
> > then log in and leave karma (feedback).
> 
> Installed the update, now it only shows lo interface.

Yes, this change is currently working around a netcf bug which you are seeing:

https://bugzilla.redhat.com/show_bug.cgi?id=1065396

WRT Comment 21 https://bugzilla.redhat.com/show_bug.cgi?id=1048351#c21 I no longer see the issue even with what's currently in the standard Updates repository (i.e. virt-manager-0.10.0-5.git1ffcc0cc.fc20.noarch). I'm not clear on when exactly the issue cleared up. So I can't comment on what's in updates-testing, sorry.

virt-manager-1.0.0-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/virt-manager-1.0.0-3.fc20

virt-manager-1.0.0-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.