[libvirt] [PATCH 00/11] Generic data stream handling

[Chris Lalancette]

Daniel P. Berrange wrote:
>> 1)  Immediately after starting the stream, I get a virStreamRecv() callback on
>> the destination side.  The problem is that this is wrong for migration; there's
>> no data that I can read *from* the destination qemu process which makes any
>> sense.  While I could implement the method and just throw away the data, that
>> doesn't seem right to me.  This leads to...
> 
> I realize this is due to the remoteAddClientStream() method in
> qemud/stream.c. It unconditionally sets 'stream->tx' to 1. I
> didn't notice the problem myself, since the test driver is using
> pipes which are unidirectional, but yor UNIX domain socket is
> bi-directional.
> 
> We could either add a flag to remoteAddClientStream() to indicate
> whether the stream should allow read or write or both. Or you
> might be able to call   shutdown(sockfd, SHUT_RD) on your UNIX
> socket to indicate that its only going to be used for write
> effectively making it unidirectional.

I tried the shutdown(sockfd, SHUT_RD) method, without success.  Then I commented
out the stream->tx = 1 line as a test, and the migration (mostly) worked.  At
least, it transferred the data to the other side, at which point trying to
"virsh console" on the destination side caused a libvirtd segfault again.  So
your idea is correct, although I think we still have a problem with the cleanup
of the stream.  I'm still debugging that.

-- 
Chris Lalancette