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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list