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

[Jim Fehlig]

Daniel P. Berrange wrote:
> 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
           ^^^^
Migration data is sent here.


>> + * - 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 ?

See above.

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

Heh, that was on my mind when responding to Michal's question about the
previous, simpler control structure

https://www.redhat.com/archives/libvir-list/2014-March/msg01196.html

There I mentioned doing most of the control work using libvirt's V3
migration protocol, keeping the libxl side of things simple.  The intent
with V4 of this patch was to make the simple libxl-side control
structure a bit extensible.  But stepping back and thinking about this
more, I think the libxl-side control could be removed completely and all
control handled by the libvirt migration protocol.  During the perform
phase, simply send the migration data to the destination, which was
prepared to receive it during the prepare phase.  Does this sound
reasonable?

> and willmake it impossible for you to support the tunnelled migration
> feature which relies on the migration data stream being unidirectional.

Good point.  Another reason to remove the libxl-side control and simply
pass the migration data to the destination.

Regards,
Jim