From nobody Sat Apr 27 00:35:12 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1596204800; cv=none; d=zohomail.com; s=zohoarc; b=TbBeqBA8RiaIyHmMSvVl+bDOi4Yzy+BVCAiCeEZI6amLKfju3aVJGsR5P7hi3FsbqBCGSR0YPirarcxPZsfeZVYEFbhBsfzubvewPnQ4b9ixMBv8uz6LCQOxEb10mBsoEJGeAiE/5noIlfZwxfzxwHUfY5zAe6/2E76QgBij+jg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1596204800; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=4TcfjXTQULo+cthrb8gZTILUP7eab23l93Ed8u0ZXaw=; b=jJyyWy94+FJKLhxqK+CcBMaDJUVqT2k6b9w39uPlzRceVbddvOudo2DR/aviWO5/iEj6thYeZMaMgIeuFdoBXT021GM8cuqYr1wxYOGMAb53xULcNlsMkiUI+Vzmy7EgwTZ/Yty+50+ejYoBm26B5VOG/Mxwdv95Px9bvpObuBY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1596204800205132.80782127910118; Fri, 31 Jul 2020 07:13:20 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-107-CIs4znxVPbeT-U4z8Le8SA-1; Fri, 31 Jul 2020 10:13:16 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4D6411005504; Fri, 31 Jul 2020 14:13:11 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F0BBE797FC; Fri, 31 Jul 2020 14:13:10 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 8A7111809554; Fri, 31 Jul 2020 14:13:09 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 06VED82Z018334 for ; Fri, 31 Jul 2020 10:13:08 -0400 Received: by smtp.corp.redhat.com (Postfix) id B2E0C5C5B7; Fri, 31 Jul 2020 14:13:08 +0000 (UTC) Received: from speedmetal.redhat.com (unknown [10.40.208.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id 13AA757 for ; Fri, 31 Jul 2020 14:13:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596204799; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=4TcfjXTQULo+cthrb8gZTILUP7eab23l93Ed8u0ZXaw=; b=UTv7SQUV1yH4qABahS81RE2YmAbbHaVRxE1fYW+CrQXZyEDlkqkaQygK7eq3b0Z0gxJYhb lpJaR0XQ+qPIJ+s/LFZF7ePkLxEAOcga08nqZOYzUJbAEUa6zvY0h5QAnaQ2YwljIkvEwv x2gme0jnmwx1uqL35gcMKw8ot2uF7yA= X-MC-Unique: CIs4znxVPbeT-U4z8Le8SA-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH] qemu: snapshot: Collect 'query-named-block-nodes' prior to memory migration Date: Fri, 31 Jul 2020 16:13:04 +0200 Message-Id: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" When doing an external snapshot we migrate memory to a file as a form of taking the memory state. This creates a problem as qemu deactivates all active bitmaps after a successful migration. This means that calling 'query-named-block-nodes' will return an empty list of bitmaps for devices. We use the bitmap list to propagate the active bitmaps into the overlay files being created which is required for backups to work after a snapshot. Since we wouldn't propagate anythign a subsequent backup will fail with: invalid argument: missing or broken bitmap 'testchck' for disk 'vda' To fix this, we can simply collect the bitmap list prior to the migration. https://bugzilla.redhat.com/show_bug.cgi?id=3D1862472 Signed-off-by: Peter Krempa Reviewed-by: Eric Blake --- Note that with current qemu the above steps will still fail as qemu fails to 'cont' after a migration if backing images contain bitmaps which is the case here. See: https://lists.nongnu.org/archive/html/qemu-block/2020-07/msg01833.html src/qemu/qemu_driver.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 0ad6359102..b655df8c98 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -15365,6 +15365,7 @@ static int qemuDomainSnapshotCreateDiskActive(virQEMUDriverPtr driver, virDomainObjPtr vm, virDomainMomentObjPtr snap, + virHashTablePtr blockNamedNodeData, unsigned int flags, virQEMUDriverConfigPtr cfg, qemuDomainAsyncJob asyncJob) @@ -15378,17 +15379,12 @@ qemuDomainSnapshotCreateDiskActive(virQEMUDriverP= tr driver, qemuDomainSnapshotDiskDataPtr diskdata =3D NULL; size_t ndiskdata =3D 0; bool blockdev =3D virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV); - g_autoptr(virHashTable) blockNamedNodeData =3D NULL; if (virDomainObjCheckActive(vm) < 0) return -1; actions =3D virJSONValueNewArray(); - if (blockdev && - !(blockNamedNodeData =3D qemuBlockGetNamedNodeData(vm, asyncJob))) - return -1; - /* prepare a list of objects to use in the vm definition so that we do= n't * have to roll back later */ if (qemuDomainSnapshotDiskPrepare(driver, vm, snap, cfg, reuse, blockd= ev, @@ -15455,6 +15451,7 @@ qemuDomainSnapshotCreateActiveExternal(virQEMUDrive= rPtr driver, int compressed; g_autoptr(virCommand) compressor =3D NULL; virQEMUSaveDataPtr data =3D NULL; + g_autoptr(virHashTable) blockNamedNodeData =3D NULL; /* If quiesce was requested, then issue a freeze command, and a * counterpart thaw command when it is actually sent to agent. @@ -15509,6 +15506,13 @@ qemuDomainSnapshotCreateActiveExternal(virQEMUDriv= erPtr driver, } } + /* We need to collect reply from 'query-named-block-nodes' prior to the + * migration step as qemu deactivates bitmaps after migration so the r= esult + * would be wrong */ + if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV) && + !(blockNamedNodeData =3D qemuBlockGetNamedNodeData(vm, QEMU_ASYNC_= JOB_SNAPSHOT))) + goto cleanup; + /* do the memory snapshot if necessary */ if (memory) { /* check if migration is possible */ @@ -15553,7 +15557,8 @@ qemuDomainSnapshotCreateActiveExternal(virQEMUDrive= rPtr driver, /* the domain is now paused if a memory snapshot was requested */ - if ((ret =3D qemuDomainSnapshotCreateDiskActive(driver, vm, snap, flag= s, cfg, + if ((ret =3D qemuDomainSnapshotCreateDiskActive(driver, vm, snap, + blockNamedNodeData, flag= s, cfg, QEMU_ASYNC_JOB_SNAPSHOT)= ) < 0) goto cleanup; --=20 2.26.2