From patchwork Mon May 9 10:59:33 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Philipp Hahn X-Patchwork-Id: 619828 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3r3KCh4NKZz9sDk for ; Mon, 9 May 2016 21:00:00 +1000 (AEST) Received: from localhost ([::1]:40581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azius-0001Kc-PJ for incoming@patchwork.ozlabs.org; Mon, 09 May 2016 06:59:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aziua-0000o9-W2 for qemu-devel@nongnu.org; Mon, 09 May 2016 06:59:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aziuW-00083Q-JP for qemu-devel@nongnu.org; Mon, 09 May 2016 06:59:39 -0400 Received: from mail.univention.de ([82.198.197.8]:1750) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aziuW-00083J-5h for qemu-devel@nongnu.org; Mon, 09 May 2016 06:59:36 -0400 Received: from localhost (localhost [127.0.0.1]) by solig.knut.univention.de (Postfix) with ESMTP id 5B2A018001DC; Mon, 9 May 2016 12:59:34 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at knut.univention.de Received: from mail.univention.de ([127.0.0.1]) by localhost (solig.knut.univention.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYm5QbaZIyrF; Mon, 9 May 2016 12:59:33 +0200 (CEST) Received: from [192.168.0.82] (mail.univention.de [82.198.197.8]) by solig.knut.univention.de (Postfix) with ESMTPSA id AAE8018001D9; Mon, 9 May 2016 12:59:33 +0200 (CEST) To: libvir-list@redhat.com, qemu-devel References: From: Philipp Hahn X-Enigmail-Draft-Status: N1110 Organization: Univention GmbH Message-ID: <57306D95.2080503@univention.de> Date: Mon, 9 May 2016 12:59:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 82.198.197.8 Subject: Re: [Qemu-devel] [libvirt] [PATCH v2 3/8] Add support for fetching statistics of completed jobs X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Orit Wasserman , Jiri Denemark Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Hi, FYI as tracking down that failure did cost me some time and hopefully this summary will help other to avoid this situation: Am 09.09.2014 um 11:54 schrieb Jiri Denemark: > virDomainGetJobStats gains new VIR_DOMAIN_JOB_STATS_COMPLETED flag that > can be used to fetch statistics of a completed job rather than a > currently running job. > > Signed-off-by: Jiri Denemark ... > --- a/src/qemu/qemu_monitor_json.c > +++ b/src/qemu/qemu_monitor_json.c > @@ -2500,7 +2500,8 @@ qemuMonitorJSONGetMigrationStatusReply(virJSONValuePtr reply, ... > - if (status->status == QEMU_MONITOR_MIGRATION_STATUS_ACTIVE) { > + if (status->status == QEMU_MONITOR_MIGRATION_STATUS_ACTIVE || > + status->status == QEMU_MONITOR_MIGRATION_STATUS_COMPLETED) { > virJSONValuePtr ram = virJSONValueObjectGet(ret, "ram"); > if (!ram) { > virReportError(VIR_ERR_INTERNAL_ERROR, "%s", > _("migration was active, but RAM 'transferred' " > "data was missing")); This change from libvirt v1.2.9-rc1~203 breaks migration with qemu-kvm-1.1.2, as that ancient implementation does *not* export transfer statistics for completed jobs: > qemuMonitorJSONCommandWithFd:286 : Send command '{"execute":"query-migrate","id":"libvirt-41"}' for write with FD -1 > qemuMonitorJSONIOProcessLine:179 : Line [{"return": {"status": "active", "ram": {"total": 2164654080, "remaining": 22474752, "transferred": 175117413}}, "id": "libvirt-41"}] ... > qemuMonitorJSONCommandWithFd:286 : Send command '{"execute":"query-migrate","id":"libvirt-42"}' for write with FD -1 > qemuMonitorJSONIOProcessLine:179 : Line [{"return": {"status": "completed"}, "id": "libvirt-42"}] As you can see, there is not "ram" section and the migration is aborted with the message: > internal error: migration was active, but no RAM info was set qemu-kvm/qmp-commands.hx even states this: > - "ram": only present if "status" is "active", it is a json-object with the > following RAM information (in bytes): but the example some lines below is wrong: > 2. Migration is done and has succeeded > > -> { "execute": "query-migrate" } > <- { "return": { > "status": "completed", > "ram":{ That example has been updated by v1.2.0-rc0~29^2~2, but forgot to update the specification above. The attached hack for libvirt makes migration work again for me by making "ram" optional in case of "completed". Philipp From c4f6dfb25042f420fdd1728865686552d928d90e Mon Sep 17 00:00:00 2001 Message-Id: From: Philipp Hahn Date: Mon, 9 May 2016 10:52:09 +0200 Subject: [PATCH] Bug #40318 libvirt: Handle qemu-kvm-1.1.2 migration incompatibility Organization: Univention GmbH, Bremen, Germany To: libvir-list@redhat.com The change from libvirt v1.2.9-rc1~203 breaks migration with qemu-kvm-1.1.2, as that ancient implementation does *not* export transfer statistics for completed jobs: > qemuMonitorJSONCommandWithFd:286 : Send command '{"execute":"query-migrate","id":"libvirt-41"}' for write with FD -1 > qemuMonitorJSONIOProcessLine:179 : Line [{"return": {"status": "active", "ram": {"total": 2164654080, "remaining": 22474752, "transferred": 175117413}}, "id": "libvirt-41"}] ... > qemuMonitorJSONCommandWithFd:286 : Send command '{"execute":"query-migrate","id":"libvirt-42"}' for write with FD -1 > qemuMonitorJSONIOProcessLine:179 : Line [{"return": {"status": "completed"}, "id": "libvirt-42"}] As you can see, there is not "ram" section and the migration is aborted with the message: > internal error: migration was active, but no RAM info was set qemu-kvm/qmp-commands.hx even states this: > - "ram": only present if "status" is "active", it is a json-object with the > following RAM information (in bytes): but the example some lines below is wrong: > 2. Migration is done and has succeeded > > -> { "execute": "query-migrate" } > <- { "return": { > "status": "completed", > "ram":{ That example has been updated by v1.2.0-rc0~29^2~2, but forgot to update the specification above. --- src/qemu/qemu_monitor_json.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index a62c02f..d3b7b90 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -2483,8 +2483,11 @@ qemuMonitorJSONGetMigrationStatusReply(virJSONValuePtr reply, if (!ram) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("migration was active, but no RAM info was set")); + if (status->status == QEMU_MONITOR_MIGRATION_STATUS_ACTIVE) { + // qemu-kvm-1.1.2 does NOT report 'ram':{...} on complete return -1; - } + } + } else { if (virJSONValueObjectGetNumberUlong(ram, "transferred", &status->ram_transferred) < 0) { @@ -2514,6 +2517,7 @@ qemuMonitorJSONGetMigrationStatusReply(virJSONValuePtr reply, virJSONValueObjectGetNumberUlong(ram, "normal", &status->ram_normal); virJSONValueObjectGetNumberUlong(ram, "normal-bytes", &status->ram_normal_bytes); + } virJSONValuePtr disk = virJSONValueObjectGet(ret, "disk"); if (disk) { -- 2.1.4