Goal

• Announce the deprecation of libslirp to customers, partners, layered products and RHEL components.
• Virtualization software shipping on RHEL 10 shall not default to libslirp networking
• Consumers of virtualization software on RHEL 10 shall be able to create virtual machines that do not use libslirp
• Layered products that depend on virtualization software on RHEL 10 shall be able to create virtual machines that do not use libslirp

Acceptance Criteria

A list of verification conditions, successful functional tests, or expected outcomes in order to declare this story/task successfully completed.

• Verify each of the goals listed above

How passt/pasta replace libslirp

User-mode networking

• maps network traffic between Layer-2 (Ethernet) frames and Layer-4 (TCP, UDP) sockets
• doesn't require root or any capabilities, no in-kernel configuration needed, no host network interfaces (outside a network namespace or a guest)
• the network interface of virtual machines and containers (Layer-2) is connected to the outside world by means of multiple sockets (Layer-4) controlled by a userspace process
• implemented by both projects

For virtual machines

libslirp

• library derived from the Slirp TCP/IP emulator
• QEMU dynamically links to it to exchange network data
• QEMU's -net user command-line option currently selects this networking option
• has significant limitations in terms of performance and IPv6 functionality
• is perceived by many as having a poor security record
• was never designed for this purpose or for production usage: hence passt

passt

• is a stand-alone application instead, and exchanges data with QEMU by means of a UNIX domain socket
• vhost-user support will optionally replace the socket interface for improved throughput and latency
• is designed to be simpler, faster, more secure
• supports IPv6 fully and enables usage of host addresses directly on the guest (no NAT)

libvirt

• supports both: it can be configured to invoke QEMU with libslirp-based networking, or to start passt and connect QEMU to it
• user-mode networking is selected via <interface type='user'/> in the domain configuration
• <backend type='passt'/> in the interface element selects passt, <backend type='default'/> selects libslirp
• uses passt by default, instead, if QEMU is not built with libslirp support
• its users, such as virt-manager and virt-install, should explicitly select passt in the domain configuration, starting from RHEL 10

For containers

The communication between the user-mode networking implementation and the container's network namespace happens via tap device: a virtual network interface in the container namespace corresponds to a file descriptor in the parent namespace.

slirp4netns

• separate application linked to libslirp, same limitations as described for libslirp above
• Podman relied on it as default for user-mode networking (rootless containers) until the Podman 4.x series (and corresponding Buildah versions)

pasta

• same binary as passt: when started as pasta, it connects to a namespace instead of listening for QEMU
• Podman uses it by default starting from the 5.x series (and corresponding Buildah versions)
• will eventually support a VDUSE interface in addition to the tap device, for improved throughput and latency