[libvirt] [RFC/Experimental]: Tunnelled migration
clalance at redhat.com
Fri Jul 17 12:59:36 UTC 2009
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:
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
- 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 38512 bytes
Desc: not available
More information about the libvir-list