[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