From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hongyang Yang Subject: Re: [PATCH v5 0/14] Migration Stream v2 Date: Thu, 12 Jun 2014 11:17:38 +0800 Message-ID: <53991BD2.4040403@cn.fujitsu.com> References: <1402510482-21099-1-git-send-email-andrew.cooper3@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1402510482-21099-1-git-send-email-andrew.cooper3@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 , Xen-devel Cc: Keir Fraser , Ian Campbell , Tim Deegan , Ian Jackson , Frediano Ziglio , David Vrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org Hi, Andrew, On 06/12/2014 02:14 AM, Andrew Cooper wrote: > Hello, > > Presented here for review is v5 of the Migration Stream v2 work. > > Major work in v5 is the legacy conversion python script which is capable of > converting from legacy to v2 format on the fly. It was tested using live > migration saving in the legacy format, piping through the script and restoring > using the v2 code. > > Other work includes a substantial refactoring of the code structure, allowing > for a single generic save() and restore() functions, with function pointer > hooks for each type of guest to implement. The spec has been updated to > include PV MSRs in the migration stream. > > > This series depends on several prerequisite fixes which have recently been > committed into staging (and have not passed the push gate at the time of > writing). The series also depends on the VM Generation ID series from David. > > I now consider the core of the v2 code stable. I do not expect it to change > much too much, other than the identified TODOs (and code review of course). > > > The next area of work is the libxl integration, which will seek to undo the > current layering violations. It will involve introducing a new libxl framing > format (which will happen to look curiously similar to the libxc framing > format), as well as providing legacy compatibility using the legacy conversion > scripts so migrations from older libxl/libxc toolstacks will continue to work. What are your plans for libxl integration, do you have any design specs or is it already implemented in the early stage? > > > The code is presented here for comment/query/critism. > > ~Andrew > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > . > -- Thanks, Yang.