From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnTZu-0007us-SZ for qemu-devel@nongnu.org; Sun, 31 Jul 2011 06:49:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QnTZt-0007Ob-PC for qemu-devel@nongnu.org; Sun, 31 Jul 2011 06:49:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnTZt-0007OV-IF for qemu-devel@nongnu.org; Sun, 31 Jul 2011 06:49:01 -0400 Message-ID: <4E353314.8070403@redhat.com> Date: Sun, 31 Jul 2011 13:48:52 +0300 From: Dor Laor MIME-Version: 1.0 References: <1309448777-1447-1-git-send-email-pbonzini@redhat.com> <4E2DFAE5.1050304@codemonkey.ws> <4E2EB522.2000808@codemonkey.ws> <4E32BD96.9030806@redhat.com> <4E32C385.5020702@codemonkey.ws> <4E32CF52.9080203@redhat.com> <4E33340D.5050003@codemonkey.ws> In-Reply-To: <4E33340D.5050003@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Ryan Harper , Stefan Hajnoczi , quintela@redhat.com, mst@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini On 07/30/2011 01:28 AM, Anthony Liguori wrote: > No, not at all. Just that converting everything to VMState isn't a > prerequisite for building a more robust migration protocol. The main thing is to priorities the problems we're facing with. - Live migration protocol: - VMState conversion is not complete - Live migration is not flexible enough (even with subsections) - Simplify destination cmdline for machine creation - Qdev - conversion is not complete - Machine + devices description are complex and have hidden glue - Qapi - Needs merging - QOB - Only the beginning So overall there are many parallel projects, probably more than the above. The RightThink(tm) would be to pick the ones that we can converge on and not try to handle all in parallel. There are problems we can live with. Engineering wise it might not be a beauty but they can wait (for instance dark magic to create the machines). There are some that prevent adding new features or make the code hard to support w/o them. Cheers, Dor ps: how hard is to finish the vmstate conversion? Can't we just assume not converted code is not functional and just remove all of it? > > Regards, > > Anthony Liguori