From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Migration v2 and related work for 4.6 Date: Wed, 15 Apr 2015 13:57:00 +0100 Message-ID: <552E601C.3020104@citrix.com> References: <551BD097.2030208@citrix.com> <20150407115910.GC14251@zion.uk.xensource.com> <1429102329.15516.265.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1429102329.15516.265.camel@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: Ian Campbell , Wei Liu Cc: Wen Congyang , Vijay Kilari , Ian Jackson , Xen-devel List , Shriram Rajagopalan , Hongyang Yang List-Id: xen-devel@lists.xenproject.org On 15/04/15 13:52, Ian Campbell wrote: > On Tue, 2015-04-07 at 12:59 +0100, Wei Liu wrote: >> On Wed, Apr 01, 2015 at 12:03:51PM +0100, Andrew Cooper wrote: >>> Hello, >>> >>> I believe I have CC'd all interested parties. If I have missed anyone, >>> please shout. >>> >>> There are several large series: >>> * Cancellable async operations >>> * COLO >>> >>> and a wish to start experimenting with migration on ARM which all >>> interact with my large series for migration v2 support in libxc and libxl. >>> >>> I am working on the libxl side of things, but realise that I am being a >>> blockage to the other areas waiting on migration v2. >>> >>> The current state of the libxc bit is functionally complete. It is >>> shipping in two versions of XenServer, has not changed substantially in >>> 9 months, and not changed in a backwards incompatible way since v1. >>> >>> I propose that the libxc series be accepted independently of the libxl >>> series. The libxc series is still implemented as an API-compatible >>> alternative to legacy migration, and is not enabled by default, meaning >>> no change to current users. >>> >>> However, it will unblock development of ARM migration and COLO, and will >>> allow people in the wider community to experiment with migration v2. An >>> existing `xl migrate` can be swapped from legacy to migration v2 simply >>> by setting an environment variable (for PV guests. HVM requires the >>> libxl changed as the handling of the Qemu save record is changing.) >>> >>> I feel that this is best interest for the community, to get some testing >>> available earlier in the development cycle, rather than attempting to >>> splice 3 large series in a related area together towards the code freeze. >>> >>> Thoughts? (especially from a release management point of view) >>> >> I've looked at your libxc series. It looks complete. I agree it would be >> good to get it in as early as possible. > I think the question is more at what point should we flip the switch and > make that new code the default without needing to set magic envvars? > > Or to take it a step further, when can we delete all the old code. The other bits needed are: * Remus/Migrationv2 (not too much, judging from the rfc set) * A decision regarding tmem. That is one bit not covered at all any of the new code, or the legacy conversion. * Libxl/migrationv2 The libxl migration v2 will contain the legacy->v2 conversion scripts, which will cover the backwards compatibility aspect. It is my hope that I can submit a very large pruning patch in time for 4.6. ~Andrew