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@xxxxxxxxxx>
>> Reviewed-by: Chuan Zheng <zhengchuan@xxxxxxxxxx>
>> ---
>> 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
