Re: [Xen-devel] [PATCH v5 RFC 01/14] docs: libxc migration stream specification

[Hongyang Yang <yanghy@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
--
Thanks,
Yang.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel