[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [libvirt] [PATCH V4] libxl: add migration support
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@xxxxxxxx> > --- > > 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 :| _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |