With this task, the subsystem team sst_cockpit is begin given official notification that the libslirp package will be deprecated in RHEL-10.0-beta. The Jira story RHEL-45147 is the tracker for all of the work related to this deprecation. At the same time, passt/pasta will become the default userspace networking solution. See the Jira story, RHEL-45241, use passt/pasta as the default userspace networking solution, for additional details.

The subsystem team is expected to review the RHEL-10 components they own and to make the necessary coding, packaging and documentation changes to adjust to the deprecation of libslirp and the support of passt/pasta; and to perform testing to verify the correct operation of their components.

Consider also the potential impact to not only customers of the subsystem's software, but other consumers of your packages as well (for example, layered products, other tools and workflows), and ensure they are also aware of--and if necessary, adapt to–this change. You may wish to create additional tasks to organize and track your work however you see fit.

Please bring any concerns and issues to the sst_virtualization_networking subsystem team as soon as possible. The product owner coordinating this change is lvivier@redhat.com.

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