qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 06/13] Add spent time for migration
Date: Wed, 11 Jul 2012 12:25:38 -0600	[thread overview]
Message-ID: <4FFDC522.9070500@redhat.com> (raw)
In-Reply-To: <20120711150817.09c87ff4@doriath.home>

[-- Attachment #1: Type: text/plain, Size: 4231 bytes --]

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
> 
> 
> 

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

  reply	other threads:[~2012-07-11 18:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1340987905.git.quintela@redhat.com>
     [not found] ` <2b6cf8e2cf421bb6645a653bd7d79a5d321faee1.1340987905.git.quintela@redhat.com>
2012-07-11 18:08   ` [Qemu-devel] [PATCH 06/13] Add spent time for migration Luiz Capitulino
2012-07-11 18:25     ` Eric Blake [this message]
2012-07-11 18:36       ` Luiz Capitulino
2012-07-11 19:32         ` Juan Quintela
2012-08-13 19:39   ` Luiz Capitulino
2012-08-13 19:46     ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FFDC522.9070500@redhat.com \
    --to=eblake@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).