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 <bogorodskiy@gmail.com> 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 <ehuels@gmail.com> --- 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... https://people.freebsd.org/~novel/misc/libvirt-e23fd0b7fd-debug/vol-download... 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.