From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Migration v2 and related work for 4.6 Date: Wed, 1 Apr 2015 12:03:51 +0100 Message-ID: <551BD097.2030208@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , Ian Campbell , Ian Jackson , Wen Congyang , Shriram Rajagopalan , Hongyang Yang , Vijay Kilari Cc: Xen-devel List List-Id: xen-devel@lists.xenproject.org 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) ~Andrew