From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNUy4-0007JJ-ON for qemu-devel@nongnu.org; Tue, 11 Mar 2014 18:16:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNUxy-0008SY-Qp for qemu-devel@nongnu.org; Tue, 11 Mar 2014 18:16:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNUxy-0008SP-HE for qemu-devel@nongnu.org; Tue, 11 Mar 2014 18:16:06 -0400 From: Juan Quintela In-Reply-To: <531F84FD.7010608@redhat.com> (Eric Blake's message of "Tue, 11 Mar 2014 15:49:49 -0600") 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> Date: Tue, 11 Mar 2014 23:15:37 +0100 Message-ID: <87mwgwz8ja.fsf@elfo.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [RFC PATCH v2 10/12] mc: expose tunable parameter for checkpointing frequency Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: GILR@il.ibm.com, SADEKJ@il.ibm.com, BIRAN@il.ibm.com, hinesmr@cn.ibm.com, qemu-devel@nongnu.org, EREZH@il.ibm.com, lig.fnst@cn.fujitsu.com, owasserm@redhat.com, onom@us.ibm.com, junqing.wang@cs2c.com.cn, mrhines@linux.vnet.ibm.com, gokul@us.ibm.com, dbulkow@gmail.com, pbonzini@redhat.com, Luiz Capitulino , abali@us.ibm.com, isaku.yamahata@gmail.com, "Michael R. Hines" Eric Blake wrote: > On 02/18/2014 01:50 AM, mrhines@linux.vnet.ibm.com wrote: >> From: "Michael R. Hines" > We're building up a LOT of migrate- tunable commands. Maybe it's time > to think about building a more generic migrate-set-parameter, which > takes both the name of the parameter to set and its value, so that a > single command serves all parameters, instead of needing a proliferation > of commands. Of course, for that to be useful, we also need a way to > introspect which parameters can be tuned; whereas with the current > approach of one command per parameter (well, 2 for set vs. get) the > introspection is based on whether the command exists. I asked to have that. My suggestion was that migrate_set_capability auto-throotle on So we could add it to new variables without extra change. And I agree that having a way to read them, and ask what values they have is a good idea. Luiz, any good idea about how to do it through QMP? Having the migration changes is easy, the problem is knowing how we want them. Later, Juan.