From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ3mQ-0001gi-Ke for qemu-devel@nongnu.org; Mon, 14 Nov 2011 16:09:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQ3mP-0002cE-DC for qemu-devel@nongnu.org; Mon, 14 Nov 2011 16:09:26 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]:39430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ3mP-0002c3-85 for qemu-devel@nongnu.org; Mon, 14 Nov 2011 16:09:25 -0500 Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 Nov 2011 16:09:19 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAEL8RGf138940 for ; Mon, 14 Nov 2011 16:08:27 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAEL8QhY006598 for ; Mon, 14 Nov 2011 19:08:26 -0200 Message-ID: <4EC18349.20203@us.ibm.com> Date: Mon, 14 Nov 2011 15:08:25 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1321114074-3681-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] migration: add a MAINTAINERS entry for migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: qemu-devel@nongnu.org On 11/14/2011 11:40 AM, Juan Quintela wrote: > Anthony Liguori wrote: >> I think this is an accurate reflection of the state of migration today. This >> is the second release in a row where we're scrambling to fix a critical issue >> in migration. > > We need to make our mind about it. Ultimately, we need to make migration a priority. That's what I'm trying to do here. The first step is to be open about the state of migration today. I personally don't have the bandwidth to invest a lot of effort in migration, but I can invest time in trying to find more people to work on migration, and help put together a proper roadmap. We need to outline and document what we support and what we don't support. We need to invest in a test infrastructure. We need a roadmap that we can reasonably execute on. In short, we need to turn migration into a first class subsystem. It's not about any single person or any single patch series. It's about deciding that migration is an important feature and deserves more focus and attention. That's the conversation I'm trying to start with this patch. Regards, Anthony Liguori > > A patch to do the reopen was posted long, long ago. Code existed on > RHEL5 from 3 years ago. Answer was that: > - we need to do it other way > - we need to change it inside qcow2 > > No suggestions for former, and internals of qcow2 are quite difficult > to grasp (at least for me). > > Then my fault for not pushing more for the patches. > > But then it happens again with migration with Huge Memory machines. > Series were rejected because it "only" fixed completely the stalls on > the iothread, and it don't fixed completely the problem on the vcpus. > And here we still are, we need to finish the migration thread to get > things included. > > And then, we have problems with the format (that is not > comprehensible). Took almost 2 years to convince you that we need a > "size", checksum, start/end markers. And we got: > - on one hand, we need to have perfect solutions to get them integrated > (huge memory patches) > - on the other hand, we can think about including patches that only fix > one of the more minor points that we have (visitors). > > So, the question is: > > What we expect for migration? > - Backward compatibility: A must for corporate users -> a burden for > everybody else > - Testing: What is that? > - Format: it is a mess, but as Avi likes to point, we would have to > "maintain" current one temporarily (a.k.a. forever). > > To make things more interesting, lots of changes on migration touch lot > of code (i.e. not only migration*/savevm.c), and getting that patches > accepted take forever. > >> The first step in fixing this problem is being up front about what the current >> state of the subsystem is. If we're going to treat migration as a release >> blocking feature in the future, than we need to promote the migration subsystem >> above 'Odd Fixes' status. > > Later, Juan. > > PD. And yes, I agree that migration is in a very sad state today. >