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 :|
