On Thu, Nov 06, 2025 at 01:37:36PM +0100, Stefano Brivio wrote:
> On Thu, 6 Nov 2025 12:08:07 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > That information might supply some clues, but it's pretty likely we'll
> > need debugging or packet capture output from passt to work this out.
> > Unfortunately, that's a bit trickier than it should be because libvirt
> > doesn't (yet) have the ability to pass the necessary options to passt.
>
> By the way, this feature request for libvirt is currently tracked at
> (public RHEL ticket, but applies to libvirt in general):
>
>   https://issues.redhat.com/browse/RHEL-52281
>
> Meanwhile, one thing you can do is to add a wrapper at
> /usr/local/bin/passt (don't forget to chmod 755 it) with these lines:
>
> ---
> #!/bin/sh
>
> /usr/bin/passt --debug --log-file /tmp/passt.log --pcap /tmp/passt.pcap $@
> ---
>
> that's the way I currently debug stuff with libvirt, at least.
>
> Note that passt can take guest-side packet captures (you would find it
> at /tmp/passt.pcap, which you can open with Wireshark / tshark later),
> which is usually convenient for cases like these.

Right.  I think this is the way forward, awkward though it is.

I was considering an alternative approach: to kill the passt instance
started by libvirt and manually restart it with the options we want.
That requires a pretty recent qemu to reliably reconnect to the new
passt, though, and generally has more places something could go wrong.
The wrapper script is the way to go, thanks for the instructions
Stefano.

--
David Gibson (he or they)       | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you, not the other way
                                | around.
http://www.ozlabs.org/~dgibson