[libvirt] [PATCH] migration: Usable time statistics without requiring NTP

[Michal Privoznik]

On 23.04.2015 11:18, Jiri Denemark wrote:
> virDomainGetJobStats is able to report statistics of a completed
> migration, however to get usable downtime and total time statistics both
> hosts have to keep synchronized time. To provide at least some
> estimation of the times even when NTP daemons are not running on both
> hosts we can just ignore the time needed to transfer a migration cookie
> to the destination host. The result will be also inaccurate but a bit
> more predictable. The total/down time will just be at least what we
> report.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1213434
> Signed-off-by: Jiri Denemark <jdenemar at redhat.com>
> ---
>  include/libvirt/libvirt-domain.h | 23 ++++++++++++++++++++++-
>  src/qemu/qemu_domain.c           | 15 +++++++++++++++
>  src/qemu/qemu_domain.h           |  9 +++++++++
>  src/qemu/qemu_migration.c        | 26 +++++++++++++-------------
>  tools/virsh-domain.c             | 16 ++++++++++++++++
>  5 files changed, 75 insertions(+), 14 deletions(-)
> 

> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 1da687c..4b3143f 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c

> @@ -3438,18 +3443,9 @@ qemuMigrationConfirmPhase(virQEMUDriverPtr driver,
>      /* Update total times with the values sent by the destination daemon */
>      if (mig->jobInfo) {
>          qemuDomainObjPrivatePtr priv = vm->privateData;
> -        if (priv->job.completed) {
> -            qemuDomainJobInfoPtr jobInfo = priv->job.completed;
> -            if (mig->jobInfo->status.downtime_set) {
> -                jobInfo->status.downtime = mig->jobInfo->status.downtime;
> -                jobInfo->status.downtime_set = true;
> -            }
> -            if (mig->jobInfo->timeElapsed)
> -                jobInfo->timeElapsed = mig->jobInfo->timeElapsed;
> -        } else {
> -            priv->job.completed = mig->jobInfo;
> -            mig->jobInfo = NULL;
> -        }
> +        VIR_FREE(priv->job.completed);
> +        priv->job.completed = mig->jobInfo;
> +        mig->jobInfo = NULL;
>      }
>  
>      if (flags & VIR_MIGRATE_OFFLINE)
> @@ -4041,6 +4037,7 @@ qemuMigrationRun(virQEMUDriverPtr driver,
>      if (priv->job.completed) {
>          qemuDomainJobInfoUpdateTime(priv->job.completed);
>          qemuDomainJobInfoUpdateDowntime(priv->job.completed);
> +        ignore_value(virTimeMillisNow(&priv->job.completed->sent));

So here you mark the time of start of the migration (on the source)...

>      }
>  
>      if (priv->job.current->type == VIR_DOMAIN_JOB_UNBOUNDED)
> @@ -5164,8 +5161,11 @@ qemuMigrationFinish(virQEMUDriverPtr driver,
>          }
>  
>          if (mig->jobInfo) {
> -            priv->job.completed = mig->jobInfo;
> +            qemuDomainJobInfoPtr jobInfo = mig->jobInfo;
> +            priv->job.completed = jobInfo;
>              mig->jobInfo = NULL;
> +            if (jobInfo->sent && virTimeMillisNow(&jobInfo->received) == 0)
> +                jobInfo->timeDelta = jobInfo->received - jobInfo->sent;

... and here, once the migration is finished, you compute the time
difference. What I am worried about is, what if time on both machines is
so off that this value makes no sense (e.g. timeDelta would be a
negative number)?

Moreover, don't we have it as a migration prerequisite that time on the
both machines needs to be synchronized? Or is this meant for much finer
granularity and I'm just babbling?

Michal