Discovered via vagrant: $ vagrant up Bringing machine 'default' up with 'libvirt' provider... Error while activating network: Call to virNetworkCreate failed: error creating bridge interface virbr0: File exists. Logs 2016-09-08 19:33:54.956+0000: 12094: info : libvirt version: 2.2.0, package: 1.fc26 (Fedora Project, 2016-09-05-14:43:34, buildvm-14.phx2.fedoraproject.org) 2016-09-08 19:33:54.956+0000: 12094: info : hostname: oat 2016-09-08 19:33:54.956+0000: 12094: error : virNetDevBridgeCreate:488 : error creating bridge interface virbr0: File exists Packages libvirt-daemon-kvm-2.2.0-1.fc26.x86_64 libvirt-daemon-driver-nodedev-2.2.0-1.fc26.x86_64 libvirt-daemon-driver-storage-2.2.0-1.fc26.x86_64 libvirt-daemon-2.2.0-1.fc26.x86_64 libvirt-daemon-driver-nwfilter-2.2.0-1.fc26.x86_64 libvirt-2.2.0-1.fc26.x86_64 rubygem-fog-libvirt-0.0.3-2.fc24.noarch libvirt-libs-2.2.0-1.fc26.x86_64 libvirt-daemon-driver-secret-2.2.0-1.fc26.x86_64 libvirt-python-2.2.0-1.fc26.x86_64 rubygem-ruby-libvirt-0.6.0-3.fc24.x86_64 libvirt-daemon-driver-qemu-2.2.0-1.fc26.x86_64 libvirt-daemon-driver-uml-2.2.0-1.fc26.x86_64 libvirt-daemon-driver-xen-2.2.0-1.fc26.x86_64 libvirt-daemon-driver-network-2.2.0-1.fc26.x86_64 libvirt-daemon-config-network-2.2.0-1.fc26.x86_64 vagrant-libvirt-0.0.33-1.fc26.noarch libvirt-daemon-driver-libxl-2.2.0-1.fc26.x86_64 libvirt-client-2.2.0-1.fc26.x86_64 libvirt-daemon-config-nwfilter-2.2.0-1.fc26.x86_64 libvirt-glib-0.2.3-2.fc24.x86_64 libvirt-daemon-driver-interface-2.2.0-1.fc26.x86_64 libvirt-daemon-driver-vbox-2.2.0-1.fc26.x86_64 libvirt-daemon-driver-lxc-2.2.0-1.fc26.x86_64
vagrant is apparently creating a transient libvirt virtual network, and has hardcoded <bridge name='virbr0'/> into that transient network's configuration, but the host already has a network that uses virbr0 (probably libvirt's "default" network, but it could be any other network - just look at "virsh net-dumpxml" for all currently active libvirt networks). vagrant should never assume that virbr0 is unused. It should instead leave the "<bridge name='virbr0'/>" out of the configuration of the network it creates, allow libvirt to automatically find an unused bridge device name, then check it after the network is started (if the bridge name is even needed anywhere else).
I'm also seeing this on Fedora 24, before a recent update this was working without issue. At present I cannot create any vagrant images. I'm seeing this issue with no VM's running, so "virsh net-dumpxml virbr0" shows nothing. However I do have the interface created: $ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 54:ee:75:43:xx:xx brd ff:ff:ff:ff:ff:ff 3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 5c:c5:d4:e2:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.3.196/24 brd 192.168.3.255 scope global dynamic wlp3s0 valid_lft 38176sec preferred_lft 38176sec inet6 fe80::e8b2:20b1:5b7b:6a62/64 scope link valid_lft forever preferred_lft forever 4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:b4:b3:5e:96 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 scope global docker0 valid_lft forever preferred_lft forever 5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 52:54:00:d1:12:89 brd ff:ff:ff:ff:ff:ff Here is an upstream ticket which appears similar in nature: https://github.com/vagrant-libvirt/vagrant-libvirt/issues/670
Fixed by deleting the network device "vagrant-libvirt" which I believe was using the device vibr0. The next instantiation of vagrant recreated the device but used vibr1.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
A workaround is to stop the virtual network "default" and disable it from auto-starting. Vagrant apparently sets up "vagrant-libvirt" without regard to bridge device conflicts with the default network.
Deleting the bridge should also fix the issue. This seems like an upstream issue (attached) and there's no reproducer so far; closing.