From: Jim Fehlig <jfehlig@suse.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xen.org
Subject: Re: [libvirt] [PATCH V4] libxl: add migration support
Date: Tue, 29 Apr 2014 09:00:04 -0600 [thread overview]
Message-ID: <535FBE74.1010604@suse.com> (raw)
In-Reply-To: <20140429092107.GD13553@redhat.com>
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@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
prev parent reply other threads:[~2014-04-29 15:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 16:43 [PATCH V4] libxl: add migration support Jim Fehlig
2014-04-29 9:21 ` [libvirt] " Daniel P. Berrange
[not found] ` <20140429092107.GD13553@redhat.com>
2014-04-29 15:00 ` Jim Fehlig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=535FBE74.1010604@suse.com \
--to=jfehlig@suse.com \
--cc=berrange@redhat.com \
--cc=libvir-list@redhat.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).