Oh, so to answer the initial question - this BZ should be closed as NOTABUG. The reporter is mixed up about where the virbrX names are used.

> libvirt-created bridges are called "virbr0"

A very common problem we encounter is with people seeing the "virbr0" style bridge device names used by libvirt when it creates transient bridges for libvirt virtual networks, then deciding that's a nice naming convention for bridges they create themselves. *then* they have problems and send parts of their ifconfig or other output to a mailing list and the people who see the name of the device there assume that they are using a libvirt-created network and offer advice accordingly, only to have that advice lead them further astray.

Because of this, whenever I see a discussion of these naming conventions I feel the need to point out that bridges created by libvirt are not used in the same manner as bridges that are created by the system network config - mixing best practices for the two leads to a horrible mess that is best remedied with a stick of dynamite and a match. The corollary is that it is *very* important to not use the virbrX style in any set of instructions detailing how to create a bridge in the system network configuration.

Also, I want to point out that, while it may work to connect to a libvirt virtual network using "<interface type='bridge'> <source bridge='virbr0'/>...", this is an extremely bad practice and should never be recommended or suggested. Instead, the guest should be connected with "<interface type='network'> <source network='default'/>..." (or whatever is the name of the libvirt network). Using type='bridge' is performing an "end-run" around libvirt's management of the network and could lead to problems in the future.

> (ie. if you have to shut down libvirt, you lose network connectivity). 

I don't understand what you're referencing here - stopping or restarting libvirtd will never cause a loss of network connectivity (the only network-related effect will be to reload all libvirt-added iptables rules which, if anything, would *restore* connectivity that may have been disrupted by some third party adding iptables rules that interfere with those previously added by libvirt).

Any networks created by libvirt will remain in service even after libvirtd is stopped. This is by design, so that upgrades can be easily performed without any service disruptions. It is true that expliciting stopping a libvirt-created *network* will cause guests using that network to lose their connectivity (and they will need to be restarted (after restarting the network) to get it back, but that doesn't match your statement.

Thanks for the explanation, Laine -- that's a very good reason for keeping any instructions with "br0" as the example.

Re:
> (ie. if you have to shut down libvirt, you lose network connectivity). 

I must have misunderstood some information I'd seen, as I had thought that if libvirtd stops, any libvirt-created bridges lose connectivity. Thanks for clarifying that, it's good to know.

As the work is complete and has been verified by SMEs, moving to VERIFIED.

The revised guest installation chapter is now publicly available as part of the most recent asynchronous docs release, and can be viewed here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/chap-Virtual_machine_installation.html

Closing > CURRENTRELEASE