[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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

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.

3) (minor) The python bindings refuse to build with these patches in place.
It's probably just a matter of fixing up the generator.py, but it needs to be done.

I've uploaded the code that I'm trying out at the moment to:

http://gitorious.org/~clalance/libvirt/clalance-staging/commits/tunnelled-migration

Dan, can you take a look and make any suggestions about where I might be going
wrong?  If you want to test out the tunnelled migration yourself, you'll need to
make sure you at least have the "exec non-blocking patch" (i.e. c/s
907500095851230a480b14bc852c4e49d32cb16d from the upstream qemu repo) in place.
 I have a qemu F-11 package with this patch in it available at:

http://people.redhat.com/clalance/qemu-exec-nonblock

-- 
Chris Lalancette


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]