All, Attached is the current version of the tunnelled migration patch, based upon danpb's generic datastream work. In order to use this work, you must first grab danpb's data-streams git branch here: http://gitorious.org/~berrange/libvirt/staging and then apply this patch on top. In some basic testing, this seems to work fine for me, although I have not given it a difficult scenario nor measured CPU utilization with these patches in place. DanB, these patches take a slightly different approach than you and I discussed yesterday on IRC. Just to recap, you suggested a new version of virMigratePrepare (called virMigratePrepareTunnel) that would take in as one of the arguments a datastream, and during the prepare step properly setup the datastream. Unless I'm missing something (which is entirely possible), this would also require passing that same datastream into the perform and finish stages, meaning that I'd essentially have an all new migration protocol version 3. To try to avoid that, during the prepare I store the port that we used to start the listening qemu in a new field in the virDomainObj structure. Then during the perform step, I create a datastream on the destination and run a new RPC function called virDomainMigratePrepareTunnel. This looks that port back up, associates it with the current stream, and returns back to the caller. Then the source side just does virStreamSend for all the data, and we have tunnelled migration. TODO: - More testing, especially under worst-case scenarios (VM constantly changing it's memory during migration) - CPU utilization testing to make sure that we aren't using a lot of CPU time doing this - Wall-clock testing - Switch over to using Unix Domain Sockets instead of localhost TCP migration. With a patch I put into upstream qemu (and is now in F-12), we can totally get rid of the scanning of localhost ports to find a free one, and just use Unix Domain Sockets. That should make the whole thing more robust. -- Chris Lalancette