From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrQSC-0006mP-Un for qemu-devel@nongnu.org; Thu, 11 Aug 2011 04:17:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrQSB-00045T-QZ for qemu-devel@nongnu.org; Thu, 11 Aug 2011 04:17:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrQSB-00045M-Ik for qemu-devel@nongnu.org; Thu, 11 Aug 2011 04:17:23 -0400 Message-ID: <4E439005.6050605@redhat.com> Date: Thu, 11 Aug 2011 11:17:09 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E3FF6AE.8030004@redhat.com> <4E3FF705.9080009@redhat.com> <4E3FFC7A.3090000@codemonkey.ws> <4E3FFD76.4010804@redhat.com> <4E400C78.1020104@codemonkey.ws> <4E40147E.2080403@redhat.com> <4E401504.7080309@codemonkey.ws> <4E429FE6.4060408@redhat.com> <4E42AABB.3020306@codemonkey.ws> <4E42ACF9.3040101@redhat.com> <4E42B07C.2090805@codemonkey.ws> <4E42B48D.9020609@redhat.com> <4E42DBAD.5030900@codemonkey.ws> In-Reply-To: <4E42DBAD.5030900@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , Stefan Hajnoczi , "Shribman, Aidan" , qemu-devel Developers , "libvir-list@redhat.com" On 08/10/2011 10:27 PM, Anthony Liguori wrote: >> This may be acceptable, wait until the entire migration cluster is >> xzbrle capable before enabling it. If not, add a monitor command. > > > 1) xzbrle needs to be disabled by default. That way management tools > don't unknowingly enable it by not passing -no-xzbrle. We could hook it to -M, though it's a bit gross. Otherwise we need to document this clearly in the management tool author's guide. > > 3) a management tool should be able to query the source and > destination, and then enable xzbrle if both sides support it. > > You can argue that (3) could be static. A command could be added to > toggle it dynamically through the monitor. > > But no matter what, someone has to touch libvirt and any other tool > that works with QEMU to make this thing work. But this is a general > problem. Any optional change to the migration protocol has exactly > the same characteristics whether it's XZBRLE, XZBRLE v2 (if there is a > v2), ASN.1, or any other form of compression that rolls around. If we have two-way communication we can do this transparently in the protocol itself. > > Instead of teaching management tools how to deal with all of these > things, let's just fix this problem once. It just takes: > > a) A query-migration-caps command that returns a dict with two lists > of strings. Something like: > > { 'execute': 'query-migration-caps' } > { 'return' : { 'capabilities': [ 'xbzrle' ], 'current': [] } } > > b) A set-migration-caps command that takes a list of strings. It > simply takes the intersection of the capabilities set with the > argument and sets the current set to the result. Something like: > > { 'execute': 'set-migration-caps', 'arguments': { 'set': [ 'xbzrle' ] }} > { 'return' : {} } > > c) An internal interface to register a capability and an internal > interface to check if a capability is currently enabled. The xzbrle > code just needs to disable itself if the capability isn't set. > > Then we teach libvirt (and other tools) to query the caps list on the > source, set the destination, query the current set on the destination, > and then set that set on the source. This is only if the capability has no side effect. > > As we introduce new things, like the next great compression protocol, > or ASN.1, we don't need to touch libvirt again. libvirt can still > know about the caps and selectively override QEMU if it's so inclined > but it prevents us from reinventing the same mechanisms over and over > again. Right. > > Yes. But that negotiation needs to become part of the "protocol" for > migration. In the absence of that negotiation, we need to use the > wire protocol we use today. We cannot have ad-hoc feature negotiation > for every change we make to the wire protocol. Okay, as long as we have someone willing to implement it. -- error compiling committee.c: too many arguments to function