From mboxrd@z Thu Jan 1 00:00:00 1970 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 References: From: Philipp Hahn Message-ID: <57306D95.2080503@univention.de> Date: Mon, 9 May 2016 12:59:33 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------080409060806000607010405" Subject: Re: [Qemu-devel] [libvirt] [PATCH v2 3/8] Add support for fetching statistics of completed jobs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: libvir-list@redhat.com, qemu-devel Cc: Jiri Denemark , Orit Wasserman This is a multi-part message in MIME format. --------------080409060806000607010405 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. >=20 > Signed-off-by: Jiri Denemark ... > --- a/src/qemu/qemu_monitor_json.c > +++ b/src/qemu/qemu_monitor_json.c > @@ -2500,7 +2500,8 @@ qemuMonitorJSONGetMigrationStatusReply(virJSONVal= uePtr reply, ... > - if (status->status =3D=3D QEMU_MONITOR_MIGRATION_STATUS_ACTIVE) { > + if (status->status =3D=3D QEMU_MONITOR_MIGRATION_STATUS_ACTIVE || > + status->status =3D=3D QEMU_MONITOR_MIGRATION_STATUS_COMPLETED)= { > virJSONValuePtr ram =3D virJSONValueObjectGet(ret, "ram"); > if (!ram) { > virReportError(VIR_ERR_INTERNAL_ERROR, "%s", > _("migration was active, but RAM 'transferre= d' " > "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-migr= ate","id":"libvirt-41"}' for write with FD -1 > qemuMonitorJSONIOProcessLine:179 : Line [{"return": {"status": "active"= , "ram": {"total": 2164654080, "remaining": 22474752, "transferred": 1751= 17413}}, "id": "libvirt-41"}] ... > qemuMonitorJSONCommandWithFd:286 : Send command '{"execute":"query-migr= ate","id":"libvirt-42"}' for write with FD -1 > qemuMonitorJSONIOProcessLine:179 : Line [{"return": {"status": "complet= ed"}, "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 >=20 > -> { "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 --------------080409060806000607010405 Content-Type: text/x-diff; name="0001-Bug-40318-libvirt-Handle-qemu-kvm-1.1.2-migration-in.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="0001-Bug-40318-libvirt-Handle-qemu-kvm-1.1.2-migration-in.pa"; filename*1="tch" =46rom 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= =2E2, as that ancient implementation does *not* export transfer statistics for com= pleted jobs: > qemuMonitorJSONCommandWithFd:286 : Send command '{"execute":"query-migr= ate","id":"libvirt-41"}' for write with FD -1 > qemuMonitorJSONIOProcessLine:179 : Line [{"return": {"status": "active"= , "ram": {"total": 2164654080, "remaining": 22474752, "transferred": 1751= 17413}}, "id": "libvirt-41"}] =2E.. > qemuMonitorJSONCommandWithFd:286 : Send command '{"execute":"query-migr= ate","id":"libvirt-42"}' for write with FD -1 > qemuMonitorJSONIOProcessLine:179 : Line [{"return": {"status": "complet= ed"}, "id": "libvirt-42"}] As you can see, there is not "ram" section and the migration is aborted w= ith 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(virJSONValu= ePtr reply, if (!ram) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("migration was active, but no RAM info was = set")); + if (status->status =3D=3D QEMU_MONITOR_MIGRATION_STATUS_ACTI= VE) { + // qemu-kvm-1.1.2 does NOT report 'ram':{...} on complet= e return -1; - } + } + } else { =20 if (virJSONValueObjectGetNumberUlong(ram, "transferred", &status->ram_transferred) <= 0) { @@ -2514,6 +2517,7 @@ qemuMonitorJSONGetMigrationStatusReply(virJSONValue= Ptr reply, virJSONValueObjectGetNumberUlong(ram, "normal", &status->ram_nor= mal); virJSONValueObjectGetNumberUlong(ram, "normal-bytes", &status->ram_normal_bytes); + } =20 virJSONValuePtr disk =3D virJSONValueObjectGet(ret, "disk"); if (disk) { --=20 2.1.4 --------------080409060806000607010405--