When using the monolithic daemon the driver for virStream is
always virFDStreamDrv and thus calling virStreamInData() results
in calling virFDStreamInData().

But things are different with split daemon, especially when a
client connects to one of hypervisor daemons (e.g. virtqemud) and
then lets the daemon connect to the storage daemon for
vol-upload/vol-download. Here, the hypervisor daemon acts like
both client and server. This is reflected by stream->driver
pointing to remoteStreamDrv, which doesn't have streamInData
callback implemented and thus vol-upload/vol-download with sparse
flag fails.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2026537
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 src/remote/remote_driver.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 235c406a5a..5b179a927d 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -5599,6 +5599,31 @@ remoteStreamRecvHole(virStreamPtr st,
 }
 
 
+static int
+remoteStreamInData(virStreamPtr st,
+                   int *data,
+                   long long *length)
+{
+    struct private_data *priv = st->conn->privateData;
+    virNetClientStream *privst = st->privateData;
+    int rv;
+
+    VIR_DEBUG("st=%p data=%p length=%p",
+              st, data, length);
+
+    remoteDriverLock(priv);
+    priv->localUses++;
+    remoteDriverUnlock(priv);
+
+    rv = virNetClientStreamInData(privst, data, length);
+
+    remoteDriverLock(priv);
+    priv->localUses--;
+    remoteDriverUnlock(priv);
+    return rv;
+}
+
+
 struct remoteStreamCallbackData {
     virStreamPtr st;
     virStreamEventCallback cb;
@@ -5745,6 +5770,7 @@ static virStreamDriver remoteStreamDrv = {
     .streamSend = remoteStreamSend,
     .streamSendHole = remoteStreamSendHole,
     .streamRecvHole = remoteStreamRecvHole,
+    .streamInData = remoteStreamInData,
     .streamFinish = remoteStreamFinish,
     .streamAbort = remoteStreamAbort,
     .streamEventAddCallback = remoteStreamEventAddCallback,
-- 
2.32.0

On Tue, Dec 07, 2021 at 04:34:42PM +0100, Michal Privoznik wrote:
>When using the monolithic daemon the driver for virStream is
>always virFDStreamDrv and thus calling virStreamInData() results
>in calling virFDStreamInData().
>
>But things are different with split daemon, especially when a
>client connects to one of hypervisor daemons (e.g. virtqemud) and
>then lets the daemon connect to the storage daemon for
>vol-upload/vol-download. Here, the hypervisor daemon acts like
>both client and server. This is reflected by stream->driver
>pointing to remoteStreamDrv, which doesn't have streamInData
>callback implemented and thus vol-upload/vol-download with sparse
>flag fails.
>
>Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2026537
>Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

Reviewed-by: Martin Kletzander <mkletzan@redhat.com>

On Wed, Dec 08, 2021 at 09:57:41PM +0100, Martin Kletzander wrote:
>On Tue, Dec 07, 2021 at 04:34:42PM +0100, Michal Privoznik wrote:
>>When using the monolithic daemon the driver for virStream is
>>always virFDStreamDrv and thus calling virStreamInData() results
>>in calling virFDStreamInData().
>>
>>But things are different with split daemon, especially when a
>>client connects to one of hypervisor daemons (e.g. virtqemud) and
>>then lets the daemon connect to the storage daemon for
>>vol-upload/vol-download. Here, the hypervisor daemon acts like
>>both client and server. This is reflected by stream->driver
>>pointing to remoteStreamDrv, which doesn't have streamInData
>>callback implemented and thus vol-upload/vol-download with sparse
>>flag fails.

Actually vol-upload does not fail for me even without these patches.
But with your patches it works both ways, so my R-b stands.

>>
>>Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2026537
>>Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
>
>Reviewed-by: Martin Kletzander <mkletzan@redhat.com>