Re: [PATCH] test: Update README.md

[Yumei Huang <yuhuang@redhat.com>]

On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> On Fri, 19 Sep 2025 09:43:29 +0800
> Yumei Huang <yuhuang@redhat.com> wrote:
>
> > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > ---
> >  test/README.md | 31 +++++++++++++++++++++++++++++--
> >  1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/test/README.md b/test/README.md
> > index 91ca603..e3e9d37 100644
> > --- a/test/README.md
> > +++ b/test/README.md
> > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > +    sipcalc socat strace tmux uidmap valgrind
> >
> >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> >
> >  ## Regular test
> >
> > -Just issue:
> > +Before running the tests, you need to prepare the required assets:
> > +
> > +    cd test
> > +    make assets
> > +
> > +Then issue:
> >
> >      ./run
> >
> > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> >
> >      PCAP=1 TRACE=1 ./run
> >
> > +**Note:**
> > +
> > +* It's recommended to run the commands as a non-root user.
> > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.
>
> Thanks for the research, I wasn't aware of that, and recently spent
> quite some time figuring that out (for other reasons):
>
>   https://issues.redhat.com/browse/RHEL-70222
>
> in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> with 'machinectl shell' instead.
>
> At the same time: running this whole stuff as root sounds rather crazy,
> unless it's a throw-away VMs with absolutely nothing important on it.
>
> That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> make the wording stronger, something like:
>
> * Don't run the tests as root, it's not needed!
> * If you really need to, note that ...
>
> > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > +  correct runtime directory is set up.
>
> We could also suggest 'machinectl shell' if it's really needed for
> whatever reason.

I'm not sure how 'machinectl shell' works here. The error happens when
running 'make assets',
which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.

If we run 'make assets' with root, the error is like this:

./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
libguestfs: error: could not create appliance through libvirt.
Original error from libvirt: Cannot access storage file
'/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
(as uid:107, gid:107): Permission denied [code=38 int1=13]

If we switch to a non-root user via 'su', the error is like this:

./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
libvirt: XML-RPC error : Cannot create user runtime directory
'/run/user/0/libvirt': Permission denied
libguestfs: error: could not connect to libvirt (URI =
qemu:///session): Cannot create user runtime directory
'/run/user/0/libvirt': Permission denied [code=38 int1=13]
make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1

Do you mean to run 'make assets' with 'machinectl shell'? What's the
exact cmd here? I tried this, seems not work.

    # machinectl shell --uid=$(id -u pat) .host
/home/test/passt/test/make assets
    Connected to the local host. Press ^] three times within 1s to exit session.

    Connection to the local host terminated.

>
> > +* SELinux may prevent the tests from running correctly. To avoid this,
> > +  temporarily disable it by running:
> > +
> > +        setenforce 0
>
> By the way, other than the DHCP client not working on Fedora in a
> namespace (which we should really fix, I can look into it if you share
> the messages you're getting from /var/log/audit/audit.log), did you hit
> any other issue with it?
>

Sure, I will send you a link containing the audit.log.
BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
:address'. Looks like an endless loop there. So except the very first
few tests, other tests haven't been executed.

=== pasta/dhcp
DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>
Interface name
DEBUG:DEBUG:? [ -n "eno8303" ]
DEBUG:DEBUG:...passed.

> DHCP: address
DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
DEBUG:DEBUG:...failed.

> DHCP: route
DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
DEBUG:DEBUG:...failed.

> DHCP: MTU
DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
DEBUG:DEBUG:...failed.

> DHCPv6: address
DEBUG:


> I haven't tried running tests on Fedora for a long time now.
>
> > +* Some tests require a QEMU build that includes the following commits:
> > +
> > +        60f543ad917f ("virtio-net: vhost-user: Implement internal migration")
> > +        3f65357313e0 ("vhost: Add stubs for the migration state transfer
> > +        interface")
>
> Given:
>
>   $ git describe --contain 60f543ad917f 3f65357313e0
>   v10.0.0-rc0~89^2~1
>   v10.0.0-rc0~89^2~2
>
> we might also save the reader from checking out a QEMU tree to check
> and say something like "Some tests require a QEMU version >= 10.0.0, or
> a build that includes ..."
>

Good idea! Will update in v2.
> > +
> >  ## Running selected tests
> >
> >  Rudimentary support to run a list of selected tests, without support for
>
> The rest looks good to me and it's an improvement on the original
> anyway so I'm fine applying as it is, as well, but those few
> suggestions shouldn't take that long either.

Sure, those are good suggestions. Thanks!
>
> --
> Stefano
>


-- 
Thanks,

Yumei Huang