What were you trying to do that didn't work?

Suggest to update the "Userspace (SLIRP or passt) connection" section in formatdomain.html for libvirt-docs

Please provide the package NVR for which bug is seen:

libvirt-9.5.0-6.el9.x86_64

How reproducible:

100%

Steps to reproduce

1. The example xml for user type interface with backend type='passt' shows "<backend type='passt' logFile='/tmp/passt.log'/>". But with passt selinux related settings, the vm will fail to start as "Couldn't open log file /tmp/passt.log: Permission denied". The only supported log directory is /run/user/$UID/. And the $UID the user id of the passt process. For root user, libvirt will start passt with qemu user. We can prepare the directory like this:

   # mkdir /run/user/107
   # chown qemu:qemu /run/user/107
   

   For non-root user, libvirt will start the passt process with this non-root user. Get the UID by "id", the directory /run/user/$UID/ should exist once the XDG_RUNTIME_DIR environment variable is set. Suggest to update the example xml to be with
   "<backend type='passt' logFile='/run/user/1000/passt.log'/>"
   And add some description that this is the non-root user's UID get by "$id".

1. And the description about "<portForward>" says like below, it doesn't mention the optional "dev" attribute which is also supported.
   "Additionally, when passt is used, multiple <portForward> elements can be added to forward incoming network traffic for the host to this guest interface. Each <portForward> must have a proto attribute (set to tcp or udp) and optional original address (if not specified, then all incoming sessions to any host IP for the given proto/port(s) will be forwarded to the guest)."

Suggest to update like this:
......Each <portForward> must have a proto attribute (set to tcp or udp) and optional original address (if not specified, then all incoming sessions to any host IP for the given proto/port(s) will be forwarded to the guest), and an optional dev attribute to limit the traffic on the specific host interface.

Refer to bug https://bugzilla.redhat.com/show_bug.cgi?id=2209191

Expected results

As above

Actual results