| Message ID | 2b6cf8e2cf421bb6645a653bd7d79a5d321faee1.1340987905.git.quintela@redhat.com |
|---|---|
| State | New |
| Headers | show |
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
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 > > >
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 > > > > > > >
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.
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
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
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
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(-)