Skip to main content
1 of 4
A.B
  • 39.6k
  • 2
  • 88
  • 134

A TAP interface provides a virtual link with two sides:

  • the interface side seen by the network layer on the host, which for OP's use case is often in tap mode (layer 2 Ethernet) and set as a bridge port.
  • an invisible side: a file descriptor opened by a process, which allows this process to read and write IP packets (tun mode) or Ethernet frames (tap mode). Those packets either comefrom or go to the interface side of the host.

Creating the interface isn't the most important part. The most important part is having a process attaching to this interface to read and inject packets. As long as there's no such process, the communication over this link doesn't exist. This is naturally translated as "NO-CARRIER". This a normal and expected behaviour.

Normally you would let qemu or an helper to qemu, or libvirtd create itself the interface (and while at it attach it to the bridge). The interface would then have this invisible other side handling it correctly: qemu, and it would report a carrier is detected.

The three most known examples of such processes are QEMU (which provides the device emulation to KVM, including network interfaces), OpenVPN and... openssh.

So if you want to have a carrier on this link you could do (as root to avoid additional settings on the interface and on openssh to enable it, so ssh must be able to connect to root)

A.B
  • 39.6k
  • 2
  • 88
  • 134