On Mon, Jan 19, 2026 at 07:43:42PM +0100, Erik Huelsmann wrote:
Hi,
While analysing traffic generated by "virsh vol-download", I noticed that the download stream exhibits the following pattern (over qemu+ssh://):
<Start> Read 4 bytes (= frame length field) Read 262144 bytes (= header + payload ; VIR_NET_MESSAGE_HEADER_MAX (24) + VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX (262120)) Read 4 bytes (= frame length field) Read 48 bytes (= header + payload) <Go back to Start>
While nothing seems to be actually wrong with this pattern, the average payload on large data transfers is only (262120+24)/2 == 131072 and the CPU makes double the iterations necessary. I'll be trying to figure out where this comes from, but I imagine that will be pretty hard to track down.
Two questions: 1. Do you see the same thing? 2. Any ideas/hints where I could start looking?
I'd suggest enabling RPC tracing with systemtap, or debug logs, to see what the messages being sent are. The 262144 byte message will be VIR_NET_STREAM with data payload. The 48 byte message is slightly surprising, but given you're using vol-download, I'm going to guess that the volume is sparse, and say this the 48 byte message is a VIR_NET_STREAM_HOLE message skipping over the transfer of a large area of zeros. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|