Virtual Bridge/Tap
 

I'm on Fedora 22 and I have libvirtd that I've been running on it. I was looking at the devices and there was a virbr0 and a virbr0-tap. Is there a concise article about how these worked? I've googled, but can't find anything very clear and it doesn't make a lot of sense to me.

The issue I have is I disconnected both the virbr0 and virbr0-tap in nmcli. virbr0 came back on a reboot, but the virbr0-tap is missing. Now when I start up my VMs they can't get out to the internet. So I'm guessing the virbr0-tap connects to the actual NIC, but how do I get that back?

This issue is now resolved. Thanks to malekmustaq for supplying the link to the answer. The actual page I needed was

https://access.redhat.com/documentat...l_network.html

You can use virt-manager to create a new connection. To get this to work I did the following:

Start virt-manager - Edit - Connection Details - Hit the + symbol to create a new connection - follow the steps to create a new connection.

Open the VM - Show virtual hardware details - NIC - Network source - choose the new network devices.

Just for the record, here's the skinny on what TAP and TUN actually are ...

Conceptually, VPN works by creating either a virtual switch, or a virtual router. Conceptually, they work exactly like their physical counterparts do.

• The TAP device (think, "telephone wiretap ...") creates a virtual switch. A switch promiscuously vacuums-up every datagram that it sees – TCP/IP or otherwise – and spews it out on the other side, and vice-versa.

• The TUN device (think, "tunnel") creates a virtual router. A router provides access to a "subnet" by means of a single "gateway" address, exactly like your home or office router provides access to the entire Internet by means of its gateway. Only TCP/IP traffic is affected. Traffic originates from an IP-address range that is shared with the subnet, and all traffic to-and-from the two sides is routed through the gateway. (Most commonly, but not necessarily, this is done via local route commands.)

An important consideration for tunnels – physical or virtual – is that the (physical) router on the remote subnet must have a static-route definition that will forward traffic (or replies) destined for the routed address-range, to the computer or device that is running OpenVPN and serving as the virtual-router for that subnet. After all, the packets must first arrive [back] at that computer, in order to then be routed through the tunnel to their final destination by it. (And, of course, this "important consideration" is true of all routers.)

HTH ...

P.S.: What I have herein described as "a switch" is more properly referred-to as a bridge, because it connects two networks together. But the essential notion is the same: "a promiscuous vacuum-cleaner." :)