[PATCH V3 0/3] migration: add qemu parallel migration options

Jiang Jiacheng jiangjiacheng at huawei.com
Fri Apr 21 09:39:12 UTC 2023


Thank you for your reply and review, I'd appreciate for you to do that.

And I'd also like to confirm that we have the following usages after the
modification.
for non-parallel migration, we can use

    --compressed
    default to use XBZRLE for migration

    --compressed --comp-methods ...
    use the specificed methods for migration

    --comp-methods ...
    use the specificed methods for migration, and set the corresponding cap

and those are forbidden since the method isn't supported with
non-parallel migration

    [--compressed] --comp-methods=zlib
    [--compressed] --comp-methods=zstd

for parallel migration, we have to enable the cap using "--parallel",
and can use like:

    --parallel
    default to NONE compression method for parallel migration

    --parallel --comp-methods ...
    use the specificed methods for parallel migration

    --parallel --compressed --comp-methods ...
    use the specificed methods for parallel migration, it's same as the
above

and those are forbidden since the method isn't supported with parallel
migration

    --parallel [--compressed] --comp-methods=mt
    --parallel [--compressed] --comp-methods=xbzrle

In particular,

    --parallel --compressed

is forbiddene because it leads to a result that NONE compression method
is chosen but compressed flag is set.
And I test it on libvirt-6.2.0 with qemu-6.2.0, '--parallel
--compressed' will set cap 'xbzrle' and 'multifd' both to true, which I
think is unreasonable though the migration is succeed.

Thanks,
Jiang Jiacheng

On 2023/4/21 1:45, Jiri Denemark wrote:
> On Fri, Feb 24, 2023 at 17:27:09 +0800, Jiang Jiacheng wrote:
>> Add compress method zlib and zstd for parallel migration and new
>> migration options to set qemu's parameter related with parallel
>> migration(multifd-compression, multifd-zlib-level and multifd-zstd-level).
>> These parameters has been supported by QEMU since 5.0.
> 
> Oh, I apologize for the delay reviewing this series. It got lost among
> all the other emails somehow. And since this is my fault, I will reply
> with suggested changes (mostly minor ones) and if you agree, I will
> squash them in and push the series.
> 
> Jirka
> 



More information about the libvir-list mailing list