On 1/18/23 06:52, Het Gala wrote: > > 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.
Understand, hopefully we can make sure that we can have a design that allows also increasing disk bandwidth for direct migration to disk. Currently upstream migration to fast disks of medium to large size VMs is badly bottlenecked by qemu/libvirt interfaces. Just FYI for existing work if interested see: https://www.mail-archive.com/libvir-list@redhat.com/msg230248.html (not upstreamable, but dramatically improves VM save/restore performance) https://lists.gnu.org/archive/html/qemu-devel/2022-10/msg02870.html (attempt to address the issue in QEMU project itself via migrating to file:///). Ciao, C
