Re: [Qemu-devel] Migration ToDo list (a.k.a. Rant)

[Markus Armbruster]

Juan Quintela <address@hidden> writes:

> Eric Blake <address@hidden> wrote:
>> On 05/04/2016 05:20 AM, Juan Quintela wrote:
>>> - migration capabilities and parameters
>>>   this is a mess.  Not, is worse than that.  I don't know who is to
>>>   blame here, but something needs to be done:
>>> 
>>>      void qmp_migrate_set_parameters(bool has_compress_level,
>>>                                 int64_t compress_level,
>>>                                 bool has_compress_threads,
>>>                                 int64_t compress_threads,
>>>                                 bool has_decompress_threads,
>>>                                 int64_t decompress_threads,
>>>                                 bool has_x_cpu_throttle_initial,
>>>                                 int64_t x_cpu_throttle_initial,
>>>                                 bool has_x_cpu_throttle_increment,
>>>                                 int64_t x_cpu_throttle_increment,
>>>                                 bool has_multifd_threads,
>>>                                 int64_t multifd_threads,
>>>                                 Error **errp)
>>
>> I've got a QAPI patch in the pipeline that makes this MUCH simpler, by
>> boxing everything through a single MigrationParameter* pointer rather
>> than an exploded list of parameters.
>
> NICE!!!

It has a pretty good chance to land in 2.7.

>>>    migrate_set_capability
>>>       Minor nickpit, if it only allow booleans,
>>> "migrate_set_capability x-multifd",
>>>       should be an equivalent of "migrate_set_capability x-multifd on"
>>
>> That's HMP - you can make HMP do whatever you want without breaking
>> back-compat.
>
> I would like to structure it as:  Use the other way, this is deprecated
> and only here for backwards compatibility.

Deprecate away; HMP is not a stable interface.

>>>    migrate_set_cache_size
>>>    migrate_set_downtime
>>>    migrate_set_speed
>>>       This three should be claimed obsolete, deprecated, whatever, and
>>>       make it on top of next one
>>
>> Again, HMP can make this change easy, even if it has to call out to
>> different QMP under the hood.
>
> Yeap, but I preffer to have both consistent.

QMP really, really wants you to use the plainest possible unit.  For
sizes, that's bytes.  For times, it should be seconds, but often isn't
(because people are deadly afraid of fractions, I guess).

HMP can and should use whatever unit(s) are needed for legible input and
output.

>>> 
>>>    Now to read the migration information:
>>> 
>>>      migrate_capabilities
>>>        good
>>>      migrate_parameters
>>>        good
>>
>> Why we need two commands is beyond me - one command that lists
>> everything (capabilities AND parameters) should be sufficient.
>
> I don't care how we do it, but we need an easy way to be sure that when
> we add a new parameter/capability we also list it.  Just now there are
> things that we can't get back.

Needs fixing.