From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hongyang Yang Subject: Re: [PATCH v5 RFC 01/14] docs: libxc migration stream specification Date: Thu, 19 Jun 2014 17:13:16 +0800 Message-ID: <53A2A9AC.70508@cn.fujitsu.com> References: <1402510482-21099-1-git-send-email-andrew.cooper3@citrix.com> <1402510482-21099-2-git-send-email-andrew.cooper3@citrix.com> <1403023215.25771.29.camel@kazak.uk.xensource.com> <53A0833F.5010907@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53A0833F.5010907@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Ian Campbell Cc: Ian Jackson , Xen-devel List-Id: xen-devel@lists.xenproject.org Hi Andrew, Ian, On 06/18/2014 02:04 AM, Andrew Cooper wrote: > On 17/06/14 17:40, Ian Campbell wrote: >> On Wed, 2014-06-11 at 19:14 +0100, Andrew Cooper wrote: >>> +The following features are not yet fully specified and will be >>> +included in a future draft. >>> + >>> +* Remus >> What is the plan for Remus here? >> >> It has pretty large implications for the flow of a migration stream and >> therefore on the code in the final two patches, I suspect it will >> require high level changes to those functions, so I'm reluctant to spend >> a lot of time on them as they are. > > I don't believe too much change will be required to the final two > patches, but it does depend on fixing the current qemu record layer > violations. > > It will be much easier to do after a prototype to the libxl level fixes. I'm trying to porting Remus to migration v2... > >>> +> of this itself. This record is only present for early development >>> +> purposes and will be removed before submissions, along with changes >>> +> to libxl which cause libxl to handle this data itself. >> How confident are you that this can be done before 4.5? I suspect that >> it's going to involve an awful lot of replumbing. > > I suspect it will, and I frankly have no idea. It is my experience in > the past that hacking on libxl turns out to be harder than expected. > >> >> I also think it will interact in exciting ways with the remus stuff. > > Less so, I think. Remus mandates identical toolstacks on either side, > so the problem of legacy remus to new remus doesn't exist. > >> >> I think we need to start seeing the start of concrete plans for both of >> these things ASAP. > > Indeed. > > The concrete plan is that it needs to be done, and it needs to be done > to a sufficient extent with general upstream approval that I can be > fairly confident that what upstream accepts isn't different to the > version which gets shipped with XenServer.$NEXT. On the other hand, > getting Xapi + libxc working for XenServer.$NEXT is critical as > customers would like to be able to migrate their vms. > > I would also like to sleep at some point. > > ~Andrew > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > -- Thanks, Yang.