Michal Prívozník wrote: > On 2/17/26 20:14, Roman Bogorodskiy wrote: > > Erik Huelsmann wrote: > > > >> Hi Roman, > >> > >> On Mon, Feb 16, 2026, 19:32 Roman Bogorodskiy <[email protected]> > >> wrote: > >> > >>> Erik Huelsmann wrote: > >>> > >>>> Before this change, buffers returned from virFDStreamRead() would > >>>> alternate in size (262120 and 24), because it only consumed the > >>>> bytes remaining from the current background thread message. > >>>> > >>>> As the background thread reads 262144 bytes (256kB) of data in > >>>> each chunk, where the maximum size returned from virFDStreamRead() > >>>> to be transferred over the remote protocol is only 262120, 24 bytes > >>>> would be left in the buffer on each iteration. The next iteration > >>>> leaves 24 bytes, which used to be returned without considering > >>>> messages waiting in the queue. > >>>> > >>>> Signed-off-by: Erik Huelsmann <[email protected]> > >>>> --- > >>>> src/util/virfdstream.c | 26 +++++++++++++++++--------- > >>>> 1 file changed, 17 insertions(+), 9 deletions(-) > >>> > >>> Hi, > >>> > >>> I noticed that with this change libvirt-tck tests started failing for > >>> me on FreeBSD: > >>> > >>> ../scripts/storage/400-vol-download.t > >>> ../scripts/storage/405-vol-download-all.t > >>> ../scripts/storage/410-vol-download-nonblock.t > >>> > >>> Things get back to normal when I revert this commit. > >>> > >>> The only thing I see in the log is: > >>> > >>> 2026-02-16 18:04:27.505+0000: 75802027180048: error : virFDStreamRead:921 > >>> : stream is not open: Bad file descriptor > >>> > >> > >> I see these are Perl scripts. Can you run the tests in verboden mode? > >> ("prove --verbose") That should provide an indication of the point in the > >> test where the error occurs > > > > root@testrunner:~/libvirt-tck # PERL5LIB=./lib > > LIBVIRT_TCK_CONFIG=/etc/libvirt-tck/default.yml prove --verbose > > ./scripts/storage/400-vol-download.t > > ./scripts/storage/400-vol-download.t .. > > 1..16 > > # Defining transient storage pool > > ok 1 - define transient storage pool > > ok 2 - built storage pool > > ok 3 - started storage pool > > ok 4 - create raw volume > > ok 5 - started download > > libvirt error code: 38, message: stream is not open: Bad file descriptor > > This is weird. I tried to reproduce locally but failed to do so. Can you > perhaps rerun with LIBVIRT_DEBUG=1 and see whether there's something > that closed the stream? Or perhaps is there an error message in libvirtd > log? > > Michal
I was able to reproduce the issue without libvirt-tck. Specifically, I created a test volume in the "dir" pool. As a test volume I just use a text file with the "hello world!" text. I download the volume using virsh like that: virsh # vol-download --pool isos test.txt /dev/null And on FreeBSD it fails with: error: cannot receive data from volume test.txt error: stream is not open: Bad file descriptor However, if I manually specify the right length (13), it works fine, e.g.: vol-download --pool isos test.txt /dev/null --length 13 The same scenario works good for me on Fedora 43. I have uploaded logs from both Linux and FreeBSD here: https://people.freebsd.org/~novel/misc/libvirt-e23fd0b7fd-debug/vol-download-freebsd.txt https://people.freebsd.org/~novel/misc/libvirt-e23fd0b7fd-debug/vol-download-linux.txt It looks like the main difference that leads to the issue is that on FreeBSD it is: daemonStreamEvent:136 : st=0x5874e821ec20 events=9 EOF=0 closed=0 Where events=9 means VIR_STREAM_EVENT_READABLE + VIR_STREAM_EVENT_HANGUP, so it goes for daemonStreamHandleRead() and fails there. On Linux, it is: daemonStreamEvent:136 : st=0x7fdd240024d0 events=8 EOF=1 closed=0 so it's not VIR_STREAM_EVENT_READABLE and it sees the EOF. I'm not yet sure why it doesn't set EOF=1 on FreeBSD.
