On 2020/10/15 18:22, Peter Krempa wrote:
On Thu, Oct 15, 2020 at 15:23:28 +0800, Hao Wang wrote:
> Introduce dirty_rate async job for qemuDomainGetDirtyRateInfo.
>
> Signed-off-by: Hao Wang <wanghao232(a)huawei.com>
> Reviewed-by: Chuan Zheng <zhengchuan(a)huawei.com>
> ---
> include/libvirt/libvirt-domain.h | 1 +
> src/qemu/qemu_domainjob.c | 3 +++
> src/qemu/qemu_domainjob.h | 1 +
> src/qemu/qemu_driver.c | 5 +++++
> src/qemu/qemu_migration.c | 2 ++
> src/qemu/qemu_process.c | 3 +++
> tools/virsh-domain.c | 1 +
> 7 files changed, 16 insertions(+)
>
> diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
> index a4b5fcc..5ed0ecd 100644
> --- a/include/libvirt/libvirt-domain.h
> +++ b/include/libvirt/libvirt-domain.h
> @@ -3295,6 +3295,7 @@ typedef enum {
> VIR_DOMAIN_JOB_OPERATION_SNAPSHOT_REVERT = 7,
> VIR_DOMAIN_JOB_OPERATION_DUMP = 8,
> VIR_DOMAIN_JOB_OPERATION_BACKUP = 9,
> + VIR_DOMAIN_JOB_OPERATION_DIRTYRATE = 10,
IMO making this a domain job will limit usefullnes of the API. domain
jobs are mutually exclusive, so you can't really use them together with
migration, where this would make the most sense to query.
Could you elaborate why you've decided to use a domain job for this? If
the only reason is that there's a domain job stats gathering API IMO it
should not be used as the main reason.
Hi, Peter.
Yes, I agree with you.
The reason why we use a domain job is that it is really mutually exclusive
with migration because we simulate log-sync like migration does in our first qemu
edition.
Now there should be no restrict for that anymore:)
.
--
Regards.
Chuan