From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrUs9-000799-Lz for qemu-devel@nongnu.org; Thu, 11 Aug 2011 09:00:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrUs4-0005VS-EX for qemu-devel@nongnu.org; Thu, 11 Aug 2011 09:00:29 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:61281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrUs4-0005VN-7C for qemu-devel@nongnu.org; Thu, 11 Aug 2011 09:00:24 -0400 Received: by ywf9 with SMTP id 9so1544655ywf.4 for ; Thu, 11 Aug 2011 06:00:23 -0700 (PDT) Message-ID: <4E43D264.8000505@codemonkey.ws> Date: Thu, 11 Aug 2011 08:00:20 -0500 From: Anthony Liguori 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: 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: "Shribman, Aidan" Cc: Blue Swirl , Stefan Hajnoczi , Avi Kivity , "libvir-list@redhat.com" , qemu-devel Developers On 08/11/2011 03:03 AM, Shribman, Aidan wrote: >> From: Anthony Liguori [mailto:anthony@codemonkey.ws] >> Sent: Wednesday, August 10, 2011 10:28 PM >> To: Avi Kivity >> Cc: Blue Swirl; Stefan Hajnoczi; Shribman, Aidan; qemu-devel >> Developers; libvir-list@redhat.com >> Subject: Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of >> large memory apps > >> 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' : {} } > > We may want to further sub-divide capabilities into categories: > { 'execute': 'query-migration-caps' } > { 'return' : > { 'encoding' : { 'current', 'asn.1', 'proto2', 'thrift', etc. } }, > { 'delta' : { 'xbzrle', "xdelta", ...} }, > { 'compression' : { 'snappy', 'lzo' } } } > This would help libvirt/management to select features automatically or manually (via UI) without having to 'understand' the any given capability meaning. I would prefer caps to be mostly transparent to libvirt. In fact, I'd like to see exactly three caps: xbzrle, asn1, and autonegotiate. I'd like to move the caps negotation into the protocol itself. >> 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. > > Agreed. Therefore caps plus xbzrle could be added before ASN.1/v1.0 without breaking anything as long as when 'set-migration-caps' is not issued Qemu uses the current protocol. Exactly. Regards, Anthony Liguori > Aidan >