# ip link 3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> 5: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> 6: tap1: <BROADCAST,MULTICAST,UP,LOWER_UP> 7: br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP>
Assign what was the host machine's IP to br0. The guests on tap0 and tap1 should have IP addresses different from this, configured within the guest. # ip route 192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.2 Now, the config that (mostly) generates the above: config_tap0="null" tuntap_tap0="tap" tunctl_tap0="-u kvm" config_tap1="null" tuntap_tap1="tap" tunctl_tap1="-u kvm" config_enp2s0="null" routes_enp2s0="null" config_br0="192.168.1.2 netmask 255.255.255.0 brd 192.168.1.255" routes_br0="default via 192.168.1.1" bridge_br0="enp2s0 tap0 tap1" rc_net_br0_need="net.tap0 net.tap1 net.enp2s0" The -u option allows users in the kvm group to manipulate the device, if you want to bring it up and down on guest start and stop. Unfortunately I don't think this produces VM interfaces that are visible outside of the subnet. I made some live changes a while ago (and need to figure out what they were - probably routing stuff). In any case, you should be able to create the tap devices and bridge them without losing connectivity. From there you can get the guests visible from the outside.
