Patchwork [06/13] Add spent time for migration

login
register
mail settings
Submitter Juan Quintela
Date June 29, 2012, 4:43 p.m.
Message ID <2b6cf8e2cf421bb6645a653bd7d79a5d321faee1.1340987905.git.quintela@redhat.com>
Download mbox | patch
Permalink /patch/168243/
State New
Headers show

Comments

Juan Quintela - June 29, 2012, 4:43 p.m.
We add time spent for migration to the output of "info migrate"
command.  'total_time' means time since the start fo migration if
migration is 'active', and total time of migration if migration is
completed.  As we are also interested in transferred ram when
migration completes, adding all ram statistics

Signed-off-by: Juan Quintela <quintela@redhat.com>
---
 hmp.c            |    2 ++
 migration.c      |   11 +++++++++++
 migration.h      |    1 +
 qapi-schema.json |   12 +++++++++---
 4 files changed, 23 insertions(+), 3 deletions(-)
Luiz Capitulino - July 11, 2012, 6:08 p.m.
On Fri, 29 Jun 2012 18:43:57 +0200
Juan Quintela <quintela@redhat.com> wrote:

> We add time spent for migration to the output of "info migrate"
> command.  'total_time' means time since the start fo migration if
> migration is 'active', and total time of migration if migration is
> completed.  As we are also interested in transferred ram when
> migration completes, adding all ram statistics

I see this has already been merged and am sorry for being late with my
review, but it turns out that there are a few issues to be addressed in
this patch, comments inlined below.

Another point is that this patch extends the query-migrate command. We've
decided not to extend QMP commands, however I think that we should relax
that restriction for query commands, because the client doesn't need to know
the new fields in advance.

> 
> Signed-off-by: Juan Quintela <quintela@redhat.com>
> ---
>  hmp.c            |    2 ++
>  migration.c      |   11 +++++++++++
>  migration.h      |    1 +
>  qapi-schema.json |   12 +++++++++---
>  4 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/hmp.c b/hmp.c
> index b9cec1d..4c6d4ae 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -145,6 +145,8 @@ void hmp_info_migrate(Monitor *mon)
>                         info->ram->remaining >> 10);
>          monitor_printf(mon, "total ram: %" PRIu64 " kbytes\n",
>                         info->ram->total >> 10);
> +        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
> +                       info->ram->total_time);

This adds a new line to the HMP output between the end of the ram stats and
the disk stats. Iirc libvirt parses this output when in non-json mode, although
I don't think it ever does it for disk migration.

Eric, does libvirt do that?

Btw, we'll need to change where 'total_time' is printed, see below.

>      }
> 
>      if (info->has_disk) {
> diff --git a/migration.c b/migration.c
> index 810727f..8db1b43 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -131,6 +131,8 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>          info->ram->transferred = ram_bytes_transferred();
>          info->ram->remaining = ram_bytes_remaining();
>          info->ram->total = ram_bytes_total();
> +        info->ram->total_time = qemu_get_clock_ms(rt_clock)
> +            - s->total_time;
> 

I really don't think that 'total_time' pertains to the ram stats info, I think
it should be in the MigrationInfo dict.


>          if (blk_mig_active()) {
>              info->has_disk = true;
> @@ -143,6 +145,13 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>      case MIG_STATE_COMPLETED:
>          info->has_status = true;
>          info->status = g_strdup("completed");
> +
> +        info->has_ram = true;
> +        info->ram = g_malloc0(sizeof(*info->ram));
> +        info->ram->transferred = ram_bytes_transferred();
> +        info->ram->remaining = 0;
> +        info->ram->total = ram_bytes_total();
> +        info->ram->total_time = s->total_time;

Having the 'total_time' in the MigrationInfo dict would avoid this change.

>          break;
>      case MIG_STATE_ERROR:
>          info->has_status = true;
> @@ -260,6 +269,7 @@ static void migrate_fd_put_ready(void *opaque)
>          } else {
>              migrate_fd_completed(s);
>          }
> +        s->total_time = qemu_get_clock_ms(rt_clock) - s->total_time;
>          if (s->state != MIG_STATE_COMPLETED) {
>              if (old_vm_running) {
>                  vm_start();
> @@ -372,6 +382,7 @@ static MigrationState *migrate_init(const MigrationParams *params)
> 
>      s->bandwidth_limit = bandwidth_limit;
>      s->state = MIG_STATE_SETUP;
> +    s->total_time = qemu_get_clock_ms(rt_clock);
> 
>      return s;
>  }
> diff --git a/migration.h b/migration.h
> index 35207bd..de13004 100644
> --- a/migration.h
> +++ b/migration.h
> @@ -37,6 +37,7 @@ struct MigrationState
>      int (*write)(MigrationState *s, const void *buff, size_t size);
>      void *opaque;
>      MigrationParams params;
> +    int64_t total_time;
>  };
> 
>  void process_incoming_migration(QEMUFile *f);
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 3b6e346..1ab5dbd 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -260,10 +260,15 @@
>  #
>  # @total: total amount of bytes involved in the migration process
>  #
> +# @total_time: tota0l amount of ms since migration started.  If

s/total0l/total

s/ms/miliseconds

> +#        migration has ended, it returns the total migration
> +#        time. (since 1.2)
> +#
>  # Since: 0.14.0.
>  ##
>  { 'type': 'MigrationStats',
> -  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' } }
> +  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
> +           'total_time': 'int' } }
> 
>  ##
>  # @MigrationInfo
> @@ -275,8 +280,9 @@
>  #          'cancelled'. If this field is not returned, no migration process
>  #          has been initiated
>  #
> -# @ram: #optional @MigrationStats containing detailed migration status,
> -#       only returned if status is 'active'
> +# @ram: #optional @MigrationStats containing detailed migration
> +#       status, only returned if status is 'active' or
> +#       'completed'. 'comppleted' (since 1.2)
>  #
>  # @disk: #optional @MigrationStats containing detailed disk migration
>  #        status, only returned if status is 'active' and it is a block
Eric Blake - July 11, 2012, 6:25 p.m.
On 07/11/2012 12:08 PM, Luiz Capitulino wrote:
> On Fri, 29 Jun 2012 18:43:57 +0200
> Juan Quintela <quintela@redhat.com> wrote:
> 
>> We add time spent for migration to the output of "info migrate"
>> command.  'total_time' means time since the start fo migration if
>> migration is 'active', and total time of migration if migration is
>> completed.  As we are also interested in transferred ram when
>> migration completes, adding all ram statistics
> 
> I see this has already been merged and am sorry for being late with my
> review, but it turns out that there are a few issues to be addressed in
> this patch, comments inlined below.
> 
> Another point is that this patch extends the query-migrate command. We've
> decided not to extend QMP commands, however I think that we should relax
> that restriction for query commands, because the client doesn't need to know
> the new fields in advance.

I see a difference between extending output (such as query command
return values), where clients can gracefully deal with the absence of a
parameter from an older qemu, and extending input (where it is hard to
tell up-front whether a parameter will be rejected by an older qemu).
This is a case of extending output, so I am okay with it; in fact, I'd
rather extend output of existing commands than add a new command,
because then libvirt has to probe which command to call, instead of
calling one command and then parsing everything available.

>> +        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
>> +                       info->ram->total_time);
> 
> This adds a new line to the HMP output between the end of the ram stats and
> the disk stats. Iirc libvirt parses this output when in non-json mode, although
> I don't think it ever does it for disk migration.
> 
> Eric, does libvirt do that?

Libvirt forces the use of QMP for qemu 0.15 and newer.  So while there
may be other users that care, libvirt could care less whether HMP output
changes between qemu 1.1 and 1.2.

>> +++ b/migration.c
>> @@ -131,6 +131,8 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>>          info->ram->transferred = ram_bytes_transferred();
>>          info->ram->remaining = ram_bytes_remaining();
>>          info->ram->total = ram_bytes_total();
>> +        info->ram->total_time = qemu_get_clock_ms(rt_clock)
>> +            - s->total_time;
>>
> 
> I really don't think that 'total_time' pertains to the ram stats info, I think
> it should be in the MigrationInfo dict.

If so, now's the time to change it before it becomes locked in stone
with the qemu 1.2 release.  Libvirt has not yet been taught to use the
new information.

>>  #
>>  # @total: total amount of bytes involved in the migration process
>>  #
>> +# @total_time: tota0l amount of ms since migration started.  If
> 
> s/total0l/total
> 
> s/ms/miliseconds

Actually, milliseconds

> 
>> +#        migration has ended, it returns the total migration
>> +#        time. (since 1.2)
>> +#
>>  # Since: 0.14.0.
>>  ##
>>  { 'type': 'MigrationStats',
>> -  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' } }
>> +  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
>> +           'total_time': 'int' } }

Also, s/total_time/total-time/ - QMP favors '-' over '_'

>>
>>  ##
>>  # @MigrationInfo
>> @@ -275,8 +280,9 @@
>>  #          'cancelled'. If this field is not returned, no migration process

Did we ever decide whether to favor US (canceled) or UK (cancelled)?

>>  #          has been initiated
>>  #
>> -# @ram: #optional @MigrationStats containing detailed migration status,
>> -#       only returned if status is 'active'
>> +# @ram: #optional @MigrationStats containing detailed migration
>> +#       status, only returned if status is 'active' or
>> +#       'completed'. 'comppleted' (since 1.2)

s/comppleted/completed/

>>  #
>>  # @disk: #optional @MigrationStats containing detailed disk migration
>>  #        status, only returned if status is 'active' and it is a block
> 
> 
>
Luiz Capitulino - July 11, 2012, 6:36 p.m.
On Wed, 11 Jul 2012 12:25:38 -0600
Eric Blake <eblake@redhat.com> wrote:

> On 07/11/2012 12:08 PM, Luiz Capitulino wrote:
> > On Fri, 29 Jun 2012 18:43:57 +0200
> > Juan Quintela <quintela@redhat.com> wrote:
> > 
> >> We add time spent for migration to the output of "info migrate"
> >> command.  'total_time' means time since the start fo migration if
> >> migration is 'active', and total time of migration if migration is
> >> completed.  As we are also interested in transferred ram when
> >> migration completes, adding all ram statistics
> > 
> > I see this has already been merged and am sorry for being late with my
> > review, but it turns out that there are a few issues to be addressed in
> > this patch, comments inlined below.
> > 
> > Another point is that this patch extends the query-migrate command. We've
> > decided not to extend QMP commands, however I think that we should relax
> > that restriction for query commands, because the client doesn't need to know
> > the new fields in advance.
> 
> I see a difference between extending output (such as query command
> return values), where clients can gracefully deal with the absence of a
> parameter from an older qemu, and extending input (where it is hard to
> tell up-front whether a parameter will be rejected by an older qemu).
> This is a case of extending output, so I am okay with it; in fact, I'd
> rather extend output of existing commands than add a new command,
> because then libvirt has to probe which command to call, instead of
> calling one command and then parsing everything available.

Yes, agreed. At least until we have libqmp...

> >> +        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
> >> +                       info->ram->total_time);
> > 
> > This adds a new line to the HMP output between the end of the ram stats and
> > the disk stats. Iirc libvirt parses this output when in non-json mode, although
> > I don't think it ever does it for disk migration.
> > 
> > Eric, does libvirt do that?
> 
> Libvirt forces the use of QMP for qemu 0.15 and newer.  So while there
> may be other users that care, libvirt could care less whether HMP output
> changes between qemu 1.1 and 1.2.

Good to know.

> 
> >> +++ b/migration.c
> >> @@ -131,6 +131,8 @@ MigrationInfo *qmp_query_migrate(Error **errp)
> >>          info->ram->transferred = ram_bytes_transferred();
> >>          info->ram->remaining = ram_bytes_remaining();
> >>          info->ram->total = ram_bytes_total();
> >> +        info->ram->total_time = qemu_get_clock_ms(rt_clock)
> >> +            - s->total_time;
> >>
> > 
> > I really don't think that 'total_time' pertains to the ram stats info, I think
> > it should be in the MigrationInfo dict.
> 
> If so, now's the time to change it before it becomes locked in stone
> with the qemu 1.2 release.  Libvirt has not yet been taught to use the
> new information.

Juan, if you agree with the change I can do it myself, or you could submit the
patch and I'll apply it to the QMP tree.

> 
> >>  #
> >>  # @total: total amount of bytes involved in the migration process
> >>  #
> >> +# @total_time: tota0l amount of ms since migration started.  If
> > 
> > s/total0l/total
> > 
> > s/ms/miliseconds
> 
> Actually, milliseconds

Thanks.

> >> +#        migration has ended, it returns the total migration
> >> +#        time. (since 1.2)
> >> +#
> >>  # Since: 0.14.0.
> >>  ##
> >>  { 'type': 'MigrationStats',
> >> -  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' } }
> >> +  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
> >> +           'total_time': 'int' } }
> 
> Also, s/total_time/total-time/ - QMP favors '-' over '_'
> 
> >>
> >>  ##
> >>  # @MigrationInfo
> >> @@ -275,8 +280,9 @@
> >>  #          'cancelled'. If this field is not returned, no migration process
> 
> Did we ever decide whether to favor US (canceled) or UK (cancelled)?

I don't think so :) Maybe we should accept both?

Would a UK grammar teacher mark 'canceled' as wrong (or vice-versa in the US)? :)

> 
> >>  #          has been initiated
> >>  #
> >> -# @ram: #optional @MigrationStats containing detailed migration status,
> >> -#       only returned if status is 'active'
> >> +# @ram: #optional @MigrationStats containing detailed migration
> >> +#       status, only returned if status is 'active' or
> >> +#       'completed'. 'comppleted' (since 1.2)
> 
> s/comppleted/completed/
> 
> >>  #
> >>  # @disk: #optional @MigrationStats containing detailed disk migration
> >>  #        status, only returned if status is 'active' and it is a block
> > 
> > 
> > 
>
Juan Quintela - July 11, 2012, 7:32 p.m.
Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Wed, 11 Jul 2012 12:25:38 -0600
> Eric Blake <eblake@redhat.com> wrote:
>
>> On 07/11/2012 12:08 PM, Luiz Capitulino wrote:
>> > On Fri, 29 Jun 2012 18:43:57 +0200
>> > Juan Quintela <quintela@redhat.com> wrote:
>> > 
>> >> We add time spent for migration to the output of "info migrate"
>> >> command.  'total_time' means time since the start fo migration if
>> >> migration is 'active', and total time of migration if migration is
>> >> completed.  As we are also interested in transferred ram when
>> >> migration completes, adding all ram statistics
>> > 
>> > I see this has already been merged and am sorry for being late with my
>> > review, but it turns out that there are a few issues to be addressed in
>> > this patch, comments inlined below.
>> > 
>> > Another point is that this patch extends the query-migrate command. We've
>> > decided not to extend QMP commands, however I think that we should relax
>> > that restriction for query commands, because the client doesn't need to know
>> > the new fields in advance.
>> 
>> I see a difference between extending output (such as query command
>> return values), where clients can gracefully deal with the absence of a
>> parameter from an older qemu, and extending input (where it is hard to
>> tell up-front whether a parameter will be rejected by an older qemu).
>> This is a case of extending output, so I am okay with it; in fact, I'd
>> rather extend output of existing commands than add a new command,
>> because then libvirt has to probe which command to call, instead of
>> calling one command and then parsing everything available.
>
> Yes, agreed. At least until we have libqmp...
>
>> >> +        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
>> >> +                       info->ram->total_time);
>> > 
>> > This adds a new line to the HMP output between the end of the ram stats and
>> > the disk stats. Iirc libvirt parses this output when in non-json
>> > mode, although
>> > I don't think it ever does it for disk migration.
>> > 
>> > Eric, does libvirt do that?
>> 
>> Libvirt forces the use of QMP for qemu 0.15 and newer.  So while there
>> may be other users that care, libvirt could care less whether HMP output
>> changes between qemu 1.1 and 1.2.
>
> Good to know.
>
>> 
>> >> +++ b/migration.c
>> >> @@ -131,6 +131,8 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>> >>          info->ram->transferred = ram_bytes_transferred();
>> >>          info->ram->remaining = ram_bytes_remaining();
>> >>          info->ram->total = ram_bytes_total();
>> >> +        info->ram->total_time = qemu_get_clock_ms(rt_clock)
>> >> +            - s->total_time;
>> >>
>> > 
>> > I really don't think that 'total_time' pertains to the ram stats
>> > info, I think
>> > it should be in the MigrationInfo dict.
>> 
>> If so, now's the time to change it before it becomes locked in stone
>> with the qemu 1.2 release.  Libvirt has not yet been taught to use the
>> new information.
>
> Juan, if you agree with the change I can do it myself, or you could submit the
> patch and I'll apply it to the QMP tree.

I can send a patch.

Thanks for the review, Juan.
Luiz Capitulino - Aug. 13, 2012, 7:39 p.m.
On Fri, 29 Jun 2012 18:43:57 +0200
Juan Quintela <quintela@redhat.com> wrote:

> We add time spent for migration to the output of "info migrate"
> command.  'total_time' means time since the start fo migration if
> migration is 'active', and total time of migration if migration is
> completed.  As we are also interested in transferred ram when
> migration completes, adding all ram statistics

I see this has already been merged and am sorry for being late with my
review, but it turns out that there are a few issues to be addressed in
this patch, comments inlined below.

Another point is that this patch extends the query-migrate command. We've
decided not to extend QMP commands, however I think that we should relax
that restriction for query commands, because the client doesn't need to know
the new fields in advance.

> 
> Signed-off-by: Juan Quintela <quintela@redhat.com>
> ---
>  hmp.c            |    2 ++
>  migration.c      |   11 +++++++++++
>  migration.h      |    1 +
>  qapi-schema.json |   12 +++++++++---
>  4 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/hmp.c b/hmp.c
> index b9cec1d..4c6d4ae 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -145,6 +145,8 @@ void hmp_info_migrate(Monitor *mon)
>                         info->ram->remaining >> 10);
>          monitor_printf(mon, "total ram: %" PRIu64 " kbytes\n",
>                         info->ram->total >> 10);
> +        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
> +                       info->ram->total_time);

This adds a new line to the HMP output between the end of the ram stats and
the disk stats. Iirc libvirt parses this output when in non-json mode, although
I don't think it ever does it for disk migration.

Eric, does libvirt do that?

Btw, we'll need to change where 'total_time' is printed, see below.

>      }
> 
>      if (info->has_disk) {
> diff --git a/migration.c b/migration.c
> index 810727f..8db1b43 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -131,6 +131,8 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>          info->ram->transferred = ram_bytes_transferred();
>          info->ram->remaining = ram_bytes_remaining();
>          info->ram->total = ram_bytes_total();
> +        info->ram->total_time = qemu_get_clock_ms(rt_clock)
> +            - s->total_time;
> 

I really don't think that 'total_time' pertains to the ram stats info, I think
it should be in the MigrationInfo dict.


>          if (blk_mig_active()) {
>              info->has_disk = true;
> @@ -143,6 +145,13 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>      case MIG_STATE_COMPLETED:
>          info->has_status = true;
>          info->status = g_strdup("completed");
> +
> +        info->has_ram = true;
> +        info->ram = g_malloc0(sizeof(*info->ram));
> +        info->ram->transferred = ram_bytes_transferred();
> +        info->ram->remaining = 0;
> +        info->ram->total = ram_bytes_total();
> +        info->ram->total_time = s->total_time;

Having the 'total_time' in the MigrationInfo dict would avoid this change.

>          break;
>      case MIG_STATE_ERROR:
>          info->has_status = true;
> @@ -260,6 +269,7 @@ static void migrate_fd_put_ready(void *opaque)
>          } else {
>              migrate_fd_completed(s);
>          }
> +        s->total_time = qemu_get_clock_ms(rt_clock) - s->total_time;
>          if (s->state != MIG_STATE_COMPLETED) {
>              if (old_vm_running) {
>                  vm_start();
> @@ -372,6 +382,7 @@ static MigrationState *migrate_init(const MigrationParams *params)
> 
>      s->bandwidth_limit = bandwidth_limit;
>      s->state = MIG_STATE_SETUP;
> +    s->total_time = qemu_get_clock_ms(rt_clock);
> 
>      return s;
>  }
> diff --git a/migration.h b/migration.h
> index 35207bd..de13004 100644
> --- a/migration.h
> +++ b/migration.h
> @@ -37,6 +37,7 @@ struct MigrationState
>      int (*write)(MigrationState *s, const void *buff, size_t size);
>      void *opaque;
>      MigrationParams params;
> +    int64_t total_time;
>  };
> 
>  void process_incoming_migration(QEMUFile *f);
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 3b6e346..1ab5dbd 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -260,10 +260,15 @@
>  #
>  # @total: total amount of bytes involved in the migration process
>  #
> +# @total_time: tota0l amount of ms since migration started.  If

s/total0l/total

s/ms/miliseconds

> +#        migration has ended, it returns the total migration
> +#        time. (since 1.2)
> +#
>  # Since: 0.14.0.
>  ##
>  { 'type': 'MigrationStats',
> -  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' } }
> +  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
> +           'total_time': 'int' } }
> 
>  ##
>  # @MigrationInfo
> @@ -275,8 +280,9 @@
>  #          'cancelled'. If this field is not returned, no migration process
>  #          has been initiated
>  #
> -# @ram: #optional @MigrationStats containing detailed migration status,
> -#       only returned if status is 'active'
> +# @ram: #optional @MigrationStats containing detailed migration
> +#       status, only returned if status is 'active' or
> +#       'completed'. 'comppleted' (since 1.2)
>  #
>  # @disk: #optional @MigrationStats containing detailed disk migration
>  #        status, only returned if status is 'active' and it is a block
Eric Blake - Aug. 13, 2012, 7:46 p.m.
On 08/13/2012 01:39 PM, Luiz Capitulino wrote:
> On Fri, 29 Jun 2012 18:43:57 +0200
> Juan Quintela <quintela@redhat.com> wrote:
> 
>> We add time spent for migration to the output of "info migrate"
>> command.  'total_time' means time since the start fo migration if
>> migration is 'active', and total time of migration if migration is
>> completed.  As we are also interested in transferred ram when
>> migration completes, adding all ram statistics
> 
> I see this has already been merged and am sorry for being late with my
> review, but it turns out that there are a few issues to be addressed in
> this patch, comments inlined below.
> 
> Another point is that this patch extends the query-migrate command. We've
> decided not to extend QMP commands, however I think that we should relax
> that restriction for query commands, because the client doesn't need to know
> the new fields in advance.
> 
>>
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> ---
>>  hmp.c            |    2 ++
>>  migration.c      |   11 +++++++++++
>>  migration.h      |    1 +
>>  qapi-schema.json |   12 +++++++++---
>>  4 files changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/hmp.c b/hmp.c
>> index b9cec1d..4c6d4ae 100644
>> --- a/hmp.c
>> +++ b/hmp.c
>> @@ -145,6 +145,8 @@ void hmp_info_migrate(Monitor *mon)
>>                         info->ram->remaining >> 10);
>>          monitor_printf(mon, "total ram: %" PRIu64 " kbytes\n",
>>                         info->ram->total >> 10);
>> +        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
>> +                       info->ram->total_time);
> 
> This adds a new line to the HMP output between the end of the ram stats and
> the disk stats. Iirc libvirt parses this output when in non-json mode, although
> I don't think it ever does it for disk migration.
> 
> Eric, does libvirt do that?

Non-issue.  Libvirt insists on using QMP (JSON mode) if qemu >= 0.15,
precisely so that changes to HMP do not affect libvirt parsing.

>> +++ b/migration.c
>> @@ -131,6 +131,8 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>>          info->ram->transferred = ram_bytes_transferred();
>>          info->ram->remaining = ram_bytes_remaining();
>>          info->ram->total = ram_bytes_total();
>> +        info->ram->total_time = qemu_get_clock_ms(rt_clock)
>> +            - s->total_time;
>>
> 
> I really don't think that 'total_time' pertains to the ram stats info, I think
> it should be in the MigrationInfo dict.

Yes, Juan took care of that in
https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg02142.html

Patch

diff --git a/hmp.c b/hmp.c
index b9cec1d..4c6d4ae 100644
--- a/hmp.c
+++ b/hmp.c
@@ -145,6 +145,8 @@  void hmp_info_migrate(Monitor *mon)
                        info->ram->remaining >> 10);
         monitor_printf(mon, "total ram: %" PRIu64 " kbytes\n",
                        info->ram->total >> 10);
+        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
+                       info->ram->total_time);
     }

     if (info->has_disk) {
diff --git a/migration.c b/migration.c
index 810727f..8db1b43 100644
--- a/migration.c
+++ b/migration.c
@@ -131,6 +131,8 @@  MigrationInfo *qmp_query_migrate(Error **errp)
         info->ram->transferred = ram_bytes_transferred();
         info->ram->remaining = ram_bytes_remaining();
         info->ram->total = ram_bytes_total();
+        info->ram->total_time = qemu_get_clock_ms(rt_clock)
+            - s->total_time;

         if (blk_mig_active()) {
             info->has_disk = true;
@@ -143,6 +145,13 @@  MigrationInfo *qmp_query_migrate(Error **errp)
     case MIG_STATE_COMPLETED:
         info->has_status = true;
         info->status = g_strdup("completed");
+
+        info->has_ram = true;
+        info->ram = g_malloc0(sizeof(*info->ram));
+        info->ram->transferred = ram_bytes_transferred();
+        info->ram->remaining = 0;
+        info->ram->total = ram_bytes_total();
+        info->ram->total_time = s->total_time;
         break;
     case MIG_STATE_ERROR:
         info->has_status = true;
@@ -260,6 +269,7 @@  static void migrate_fd_put_ready(void *opaque)
         } else {
             migrate_fd_completed(s);
         }
+        s->total_time = qemu_get_clock_ms(rt_clock) - s->total_time;
         if (s->state != MIG_STATE_COMPLETED) {
             if (old_vm_running) {
                 vm_start();
@@ -372,6 +382,7 @@  static MigrationState *migrate_init(const MigrationParams *params)

     s->bandwidth_limit = bandwidth_limit;
     s->state = MIG_STATE_SETUP;
+    s->total_time = qemu_get_clock_ms(rt_clock);

     return s;
 }
diff --git a/migration.h b/migration.h
index 35207bd..de13004 100644
--- a/migration.h
+++ b/migration.h
@@ -37,6 +37,7 @@  struct MigrationState
     int (*write)(MigrationState *s, const void *buff, size_t size);
     void *opaque;
     MigrationParams params;
+    int64_t total_time;
 };

 void process_incoming_migration(QEMUFile *f);
diff --git a/qapi-schema.json b/qapi-schema.json
index 3b6e346..1ab5dbd 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -260,10 +260,15 @@ 
 #
 # @total: total amount of bytes involved in the migration process
 #
+# @total_time: tota0l amount of ms since migration started.  If
+#        migration has ended, it returns the total migration
+#        time. (since 1.2)
+#
 # Since: 0.14.0.
 ##
 { 'type': 'MigrationStats',
-  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' } }
+  'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
+           'total_time': 'int' } }

 ##
 # @MigrationInfo
@@ -275,8 +280,9 @@ 
 #          'cancelled'. If this field is not returned, no migration process
 #          has been initiated
 #
-# @ram: #optional @MigrationStats containing detailed migration status,
-#       only returned if status is 'active'
+# @ram: #optional @MigrationStats containing detailed migration
+#       status, only returned if status is 'active' or
+#       'completed'. 'comppleted' (since 1.2)
 #
 # @disk: #optional @MigrationStats containing detailed disk migration
 #        status, only returned if status is 'active' and it is a block