[libvirt] [PATCH V4] libxl: add migration support

[Daniel P. Berrange]

On Mon, Apr 28, 2014 at 10:43:10AM -0600, Jim Fehlig wrote:
> This patch adds initial migration support to the libxl driver,
> using the VIR_DRV_FEATURE_MIGRATION_PARAMS family of migration
> functions.
> 
> Signed-off-by: Jim Fehlig <jfehlig at suse.com>
> ---
> 
> V3 here
>   https://www.redhat.com/archives/libvir-list/2014-April/msg00968.html
> 
> In V4:
> - Code cleanup
> - Improved error handling
> 
> Although this patch has been floating around for a long time, not sure
> if it is 1.2.4 material since it brings a new feature to the libxl
> driver.


> +/*
> + * For future extensibility, a simple messaging protocol used to send migration
> + * data between libxl hosts.  The message is encapsulated in json and currently
> + * includes the following entries:
> + *
> + * {"libvirt-libxl-mig-msg" :
> + *   {"version" : $ver},
> + *   {"state" : $state},
> + *   {"status" : $status}
> + * }
> + *
> + * Possible $state values are "negotiate-version", "send-binary-data",
> + * "sending-binary-data", "received-binary-data", "done", and "error".
> + *
> + * Migration between source and destination libxl hosts is performed with the
> + * following message exchange:
> + *
> + * - src->dst: connect
> + * - dst->src: state="negotiate-version", version=LIBXL_MIGRATION_PROTO_VERSION
> + * - src->dst: state-"negotiate-version",
> + *             version=min(dst ver,  LIBXL_MIGRATION_PROTO_VERSION)
> + * - dst->src: state="send-binary-data", version=negotiated_version
> + * - src->dst: state="sending-binary-data", version=negotiated_version
> + * _ src->dst: binary migration data
> + * - dst->src: state="received-binary-data", version=negotiated_version
> + * - src->dst: state="done", version=negotiated_version
> + *
> + */

Maybe I'm missing something, but where is the actual migration payload
data being transferred ? None of the messages above contain any data ?

I'm also a little wary of the fact that you're building a bi-directional
control structure here. This seems to have alot of overlap with the
handshake / control structure already built into the virDomainMigrateXXX
steps, and willmake it impossible for you to support the tunnelled migration
feature which relies on the migration data stream being unidirectional.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|