From: Juan Quintela <quintela@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: aliguori@us.ibm.com, Eric Blake <eblake@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 06/13] Add spent time for migration
Date: Wed, 11 Jul 2012 21:32:25 +0200 [thread overview]
Message-ID: <87hate6qly.fsf@elfo.mitica> (raw)
In-Reply-To: <20120711153631.6af83928@doriath.home> (Luiz Capitulino's message of "Wed, 11 Jul 2012 15:36:31 -0300")
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.
next prev parent reply other threads:[~2012-07-11 19:32 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
2012-07-11 18:36 ` Luiz Capitulino
2012-07-11 19:32 ` Juan Quintela [this message]
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=87hate6qly.fsf@elfo.mitica \
--to=quintela@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=eblake@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).