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

[Juan Quintela <quintela@redhat.com>]

Eric Blake <eblake@redhat.com> 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!!!

>>    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.

>>    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.


>> 
>>    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.

Later, Juan.