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

[Daniel P. Berrange]

On Tue, Sep 15, 2009 at 02:35:02PM +0200, Chris Lalancette wrote:
> Daniel P. Berrange wrote:
> > The immediate use case for this data stream code is Chris' QEMU
> > migration patchset.
> > 
> > The next use case is to allow serial console access to be tunnelled
> > over libvirtd, eg to make  'virsh console GUEST' work remotely.
> > This use case is why I included the support for non-blocking data
> > streams and event loop integration (not required for Chris'
> > migration use case)
> > 
> > Anyway, assuming Chris confirms that I've not broken his code, then
> > patches 1-6 are targetted for this next release.
> 
> I'm sorry for the very long delay in getting back to this.  I've been playing
> around with my tunnelled migration patches on top of this code, and I just can't
> seem to make the new nonblocking stuff work properly.  I'm getting a couple of
> behaviors that are highly undesirable:
> 
> 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.

A 3rd option is to define more flags for virStreamNew(), one for
READ, one for WRITE, and have the remote daemon pay attention to
these

> 2)  A crash in libvirtd on the source side of the destination.  It doesn't
> happen every single time, but when it has happened I've traced it down to the
> fact that src/remote_internal.c:remoteDomainEventFired() can get called *after*
> conn->privateData has been set to NULL, leading to a SEGV on NULL pointer
> dereference.  I can provide a core-dump for this if needed.

I don't have any explanation for this - its a little wierd and we ought
to try and figure it out if possible.

> 3) (minor) The python bindings refuse to build with these patches in place.

Yeah I completely forgot to add rules for virSecret APIs there

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|