From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnd4e-0000n5-Gt for qemu-devel@nongnu.org; Sun, 31 Jul 2011 16:57:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qnd4d-00057w-Hv for qemu-devel@nongnu.org; Sun, 31 Jul 2011 16:57:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnd4d-00057c-9n for qemu-devel@nongnu.org; Sun, 31 Jul 2011 16:57:23 -0400 Message-ID: <4E35C1A9.5040209@redhat.com> Date: Sun, 31 Jul 2011 23:57:13 +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> <4E353314.8070403@redhat.com> <4E35BE77.2050907@codemonkey.ws> In-Reply-To: <4E35BE77.2050907@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/31/2011 11:43 PM, Anthony Liguori wrote: > On 07/31/2011 05:48 AM, Dor Laor wrote: >> 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 > > But this is not a problem because it doesn't gate anything. That's my > point. The VMState might be an exception but in general we have too many unfinished businesses going on. > >> - Live migration is not flexible enough (even with subsections) > > To make it more flexible, we need to be able to marshal to an internal > data structure that we can transform in more flexible ways. > >> - Simplify destination cmdline for machine creation > > This needs qdev fixing. > >> - Qdev >> - conversion is not complete >> - Machine + devices description are complex and have hidden glue > > This is a hard problem. > >> - Qapi >> - Needs merging > > We merged the first part (which includes the new QMP server). The work > is done for converting the actual QMP commands. > >> - 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? > > No. VMState is a solution looking for a problem. Many important device The initial target solved some rare bugs, that tend not to bite us with virtio. On the way, it got enhanced with subsections that was a major improvement. > models are still not converted and ultimately, it doesn't solve the > problem we're really trying to solve. From the start I supported Michael Tisrkin's idea for ASN.1 protocol. The question is how visitors and ability to translate from one representation to another will help us. I do see value in it but I don't think it is that important. If we have one real device serialization method that is flexible enough we can stick with it w/o translation. If we define qdev serialization into vmstate/asn.1/json/other and add some capability negotiation and various other goodies it should be enough. btw: separating the live migration protocol from the machine state is even more important if we take a gradual approach. > > Regards, > > Anthony Liguori > >> >>> >>> Regards, >>> >>> Anthony Liguori >> >> >> > >