From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYUhS-0007th-SQ for qemu-devel@nongnu.org; Fri, 11 Apr 2014 02:12:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYUhM-0001c8-0V for qemu-devel@nongnu.org; Fri, 11 Apr 2014 02:12:30 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:36879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYUhL-0001c1-S7 for qemu-devel@nongnu.org; Fri, 11 Apr 2014 02:12:23 -0400 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 11 Apr 2014 02:12:22 -0400 Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3F7AF38C803D for ; Fri, 11 Apr 2014 02:12:20 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp22034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s3B6CKw27471500 for ; Fri, 11 Apr 2014 06:12:20 GMT Received: from d01av01.pok.ibm.com (localhost [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s3B6CJSm027264 for ; Fri, 11 Apr 2014 02:12:20 -0400 Message-ID: <5347875C.3050905@linux.vnet.ibm.com> Date: Fri, 11 Apr 2014 14:10:36 +0800 From: "Michael R. Hines" MIME-Version: 1.0 References: <1392713429-18201-1-git-send-email-mrhines@linux.vnet.ibm.com> <1392713429-18201-11-git-send-email-mrhines@linux.vnet.ibm.com> <531F84FD.7010608@redhat.com> <87mwgwz8ja.fsf@elfo.mitica> <531F9300.50304@redhat.com> <533E4331.2020202@linux.vnet.ibm.com> <533EC83A.1090005@redhat.com> In-Reply-To: <533EC83A.1090005@redhat.com> Content-Type: multipart/alternative; boundary="------------080609070505030101060904" Subject: Re: [Qemu-devel] [RFC PATCH v2 10/12] mc: expose tunable parameter for checkpointing frequency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , quintela@redhat.com Cc: GILR@il.ibm.com, SADEKJ@il.ibm.com, pbonzini@redhat.com, abali@us.ibm.com, qemu-devel@nongnu.org, EREZH@il.ibm.com, Luiz Capitulino , owasserm@redhat.com, onom@us.ibm.com, hinesmr@cn.ibm.com, isaku.yamahata@gmail.com, gokul@us.ibm.com, dbulkow@gmail.com, junqing.wang@cs2c.com.cn, BIRAN@il.ibm.com, lig.fnst@cn.fujitsu.com, "Michael R. Hines" This is a multi-part message in MIME format. --------------080609070505030101060904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/04/2014 10:56 PM, Eric Blake wrote: > On 04/03/2014 11:29 PM, Michael R. Hines wrote: >>> I'm trying to thing of a back-compat method, which exploits the fact >>> that we now have flat unions (something we didn't have when >>> migrate-set-capabilities was first added). Maybe something like: >>> >>> { 'type': 'MigrationCapabilityBase', >>> 'data': { 'capability': 'MigrationCapability' } } >>> { 'type': 'MigrationCapabilityBool', >>> 'data': { 'state': 'bool' } } >>> { 'type': 'Migration CapabilityInt', >>> 'data': { 'value': 'int' } } >>> { 'union': 'MigrationCapabilityStatus', >>> 'base': 'MigrationCapabilityBase', >>> 'discriminator': 'capability', >>> 'data': { >>> 'xbzrle': 'MigrationCapabilityBool', >>> 'auto-converge': 'MigrationCapabilityBool', >>> ... >>> 'mc-delay': 'MigrationCapabilityInt' >>> } } >>> >>> along with a tweak to query-migrate-capabilities for full back-compat: >>> >>> # @query-migrate-capabilities >>> # @extended: #optional defaults to false; set to true to see non-boolean >>> capabilities (since 2.1) >>> { 'command: 'query-migrate-capabilities', >>> 'data': { '*extended': 'bool' }, >>> 'returns': ['MigrationCapabilityStatus'] } >>> >> I like this a lot - it's very complicated, but it is clean, I think. > Good - that means I made sense in trying to explain it. And the more I > re-read my mail, the more I like the idea - fewer new commands, and make > the existing commands both more powerful and more easily extensible, all > while still being discoverable by libvirt without waiting for full > schema introspection. Alright, I've saved this proposal on the wiki on the MicroCheckpointing TODO section: http://wiki.qemu.org/Features/MicroCheckpointing#TODO For now, I've got several other issues to address before "someone" gets around to this (I'd assume the maintainer or someone else would want to test the 'extended' feature by itself in isolation with the existing set of migration commands before someone else like me attempts to use it or start adding new features to it.) - Michael --------------080609070505030101060904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 04/04/2014 10:56 PM, Eric Blake wrote:
On 04/03/2014 11:29 PM, Michael R. Hines wrote:

I'm trying to thing of a back-compat method, which exploits the fact
that we now have flat unions (something we didn't have when
migrate-set-capabilities was first added).  Maybe something like:

{ 'type': 'MigrationCapabilityBase',
   'data': { 'capability': 'MigrationCapability' } }
{ 'type': 'MigrationCapabilityBool',
   'data': { 'state': 'bool' } }
{ 'type': 'Migration CapabilityInt',
   'data': { 'value': 'int' } }
{ 'union': 'MigrationCapabilityStatus',
   'base': 'MigrationCapabilityBase',
   'discriminator': 'capability',
   'data': {
     'xbzrle': 'MigrationCapabilityBool',
     'auto-converge': 'MigrationCapabilityBool',
...
     'mc-delay': 'MigrationCapabilityInt'
   } }

along with a tweak to query-migrate-capabilities for full back-compat:

# @query-migrate-capabilities
# @extended: #optional defaults to false; set to true to see non-boolean
capabilities (since 2.1)
{ 'command: 'query-migrate-capabilities',
   'data': { '*extended': 'bool' },
   'returns': ['MigrationCapabilityStatus'] }



      

        
I like this a lot - it's very complicated, but it is clean, I think.


      

      
Good - that means I made sense in trying to explain it.  And the more I
re-read my mail, the more I like the idea - fewer new commands, and make
the existing commands both more powerful and more easily extensible, all
while still being discoverable by libvirt without waiting for full
schema introspection.


    

    

    Alright, I've saved this proposal on the wiki on the
    MicroCheckpointing

    TODO section:

    

    
    http://wiki.qemu.org/Features/MicroCheckpointing#TODO

    

    For now, I've got several other issues to address before "someone"

    gets around to this (I'd assume the maintainer or someone else would

    want to test the 'extended' feature by itself in isolation with the
    existing

    set of migration commands before someone else like me attempts to 

    use it or start adding new features to it.)

    

    - Michael

    

  


--------------080609070505030101060904--