> > # @auto-converge: If enabled, QEMU will automatically throttle down the
> > guest
> > # to speed up convergence of RAM migration. (since 1.6)
> > #
> > # Since: 1.2
> > ##
> > { 'enum': 'MigrationCapability',
> > - 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks']
> > }
> > + 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
> > + 'compress'] }
> >
> I'll repeat what I said on v1 (but this time, with some links to back it up :)
> We really need to avoid a proliferation of new commands, two per tunable does
> not scale well. I think now is the time to implement my earlier suggestion
> at making MigrationCapability become THE resource for > tunables:
> https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg02274.html
Hi, Eric
I have read your proposal, and I just want to verify if I got it
exactly. Take the 'compresss-level' parameter for example, according to you
suggestion, should I implement a command 'set-migrate-capability compress-level
1', or 'set-migrate-parameter compress-level 1' ? if it's the former, how to
keep the HMP back compatibility, as you know, the current HMP framework will
check the parameter type, the 'int' will be processed differently from 'bool',
; if it's the latter, it seems like a ' query-migrate-paramer ' command
should be provided to keep consistency, not query-migrate-capability.
Liang
