From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNVUi-0006Z4-BY for qemu-devel@nongnu.org; Tue, 11 Mar 2014 18:50:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNVUd-0002Yz-EM for qemu-devel@nongnu.org; Tue, 11 Mar 2014 18:49:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNVUd-0002Yr-5l for qemu-devel@nongnu.org; Tue, 11 Mar 2014 18:49:51 -0400 Message-ID: <531F9300.50304@redhat.com> Date: Tue, 11 Mar 2014 16:49:36 -0600 From: Eric Blake 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> In-Reply-To: <87mwgwz8ja.fsf@elfo.mitica> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hlKLC0uHEKWfq7WfkPqEnbv3SRR2exlc6" 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: quintela@redhat.com 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" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hlKLC0uHEKWfq7WfkPqEnbv3SRR2exlc6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/11/2014 04:15 PM, Juan Quintela wrote: > Eric Blake wrote: >> On 02/18/2014 01:50 AM, mrhines@linux.vnet.ibm.com wrote: >>> From: "Michael R. Hines" >=20 >> 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 proliferati= on >> 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. >=20 > I asked to have that. My suggestion was that >=20 > migrate_set_capability auto-throotle on >=20 > So we could add it to new variables without extra change. >=20 > And I agree that having a way to read them, and ask what values they > have is a good idea. >=20 > Luiz, any good idea about how to do it through QMP? 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', =2E.. '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'] } Now, observe what happens. If an old client calls { "execute": "query-migrate-capabilities" }, they get a return that lists ONLY the boolean members of the MigrationCapabilityStatus array (good, because if we returned a non-boolean, we would confuse the consumer when they are expecting a 'state' variable that is not present) - what's more, this representation is identical on the wire to the format used in earlier qemu. But new clients can call { "execute": "query-migrate-capabilities", "arguments": { "extended": true } }, and get back: { "capabilities": [ { "capability": "xbzrle", "state": true }, { "capability": "auto-converge", "state": false }, =2E.. { "capability": "mc-delay", "value": 100 } ] } Also, once a new client has learned of non-boolean extended capabilities, they can also set them via the existing command: { "execute": "migrate-set-capabilities", "arguments": [ { "capability": "xbzrle", "state", false }, { "capability": "mc-delay", "value", 200 } ] } So, what do you think? My slick type manipulation means that we need zero new commands, just a new option the the query command, and a new flat union type that replaces the current struct type. The existence (but not the type) of non-boolean parameters is already introspectible to a client new enough to request an 'extended' query, and down the road, if we ever gain full QAPI introspection, then a client also would gain the ability to learn the type of any non-boolean parameter as well. Stability wise, as long as we never change the type of a capability once first exposed, then if a client plans on using a particular parameter when available, it can already hard-code what type that parameter should have without even needing full QAPI introspection (that is, if libvirt is taught to manipulate mc-delay, libvirt will already know to expect mc-delay as an int, and not any other type, and merely needs to probe if qemu supports the 'mc-delay' extended capability). And of course, this new schema idea can retroactively cover all existing migration tunables, such as migrate_set_downtime, migrate_set_speed, migrate-set-cache-size, and so on. >=20 > Having the migration changes is easy, the problem is knowing how we wan= t > them. And maybe my proposal just solved that. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --hlKLC0uHEKWfq7WfkPqEnbv3SRR2exlc6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTH5MAAAoJEKeha0olJ0Nqa4YH/jalqEgPOlsaZg17fn7wFOEv zNw9aq+3AXT82lkiHySeDjVJBdu98Rr+2IJ5Ys1LrrvH8v+G7gZdWIz8BE3+ZGbO /kID5e/2LTQJ+zwdu2WcSlRZcL1ZILFqwOgRAmaguJ7HBUiV8SWaQLNskl76GvAb bThmTw6Ldp6QyAzxVYBklIDCnyppt3VUnBDeSZUta7zhNTFZNERdoML8s+UKEVM5 BlKQSHFo7JGPZwbSkSzKgJQNGlW52YgXltH/hEXAsdC5mUaN68Zriyp0YEAdeseP Fr4txYT2ZKhzopsceySIRf1za2/1dJuJdFi6rKlXmXRJtVaid3kfZ2BwlnDhYOk= =0u/4 -----END PGP SIGNATURE----- --hlKLC0uHEKWfq7WfkPqEnbv3SRR2exlc6--