On 17/01/23 4:22 pm, Claudio Fontana wrote:
Hi, On 12/26/22 06:33, Het Gala wrote:Current QAPI 'migrate' command design (for initiating a migration stream) contains information regarding different migrate transport mechanism (tcp / unix / exec), dest-host IP address, and binding port number in form of a string. Thus the design does seem to have some design issues. Some of the issues, stated below are: 1. Use of string URIs is a data encoding scheme within a data encoding scheme. QEMU code should directly be able to work with the results from QAPI, without resorting to do a second level of parsing (eg. socket_parse()). 2. For features / parameters related to migration, the migration tunables needs to be defined and updated upfront. For example, 'migrate-set-capability' and 'migrate-set-parameter' is required to enable multifd capability and multifd-number of channels respectively. Instead, 'Multifd-channels' can directly be represented as a single additional parameter to 'migrate' QAPI. 'migrate-set-capability' and 'migrate-set-parameter' commands could be used for runtime tunables that need setting after migration has already started.Is efficient and parallel migration to file of large VMs in scope for this design? Thanks, Claudio
This patch's design right now mainly focuses on revamping the design for 'migrate' command.
In the upcomig patchset series in future, it will try to accomodate multifd as a feature in the same QAPI command and try to build multiple interface support on top of multifd feature. Main aim is to increase network bandwidth for migration with help of multiple interface and multifd.
Regards, Het Gala.
