From nobody Sun Apr 28 09:54:06 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 15047258745351018.9123753113635; Wed, 6 Sep 2017 12:24:34 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6654BC0587C6; Wed, 6 Sep 2017 19:24:32 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B24F5179CF; Wed, 6 Sep 2017 19:24:30 +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 B591A4EE50; Wed, 6 Sep 2017 19:24:25 +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 v86JONA2022898 for ; Wed, 6 Sep 2017 15:24:23 -0400 Received: by smtp.corp.redhat.com (Postfix) id A9EEC17143; Wed, 6 Sep 2017 19:24:23 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-116-120.phx2.redhat.com [10.3.116.120]) by smtp.corp.redhat.com (Postfix) with ESMTP id 73A205C544 for ; Wed, 6 Sep 2017 19:24:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6654BC0587C6 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=libvir-list-bounces@redhat.com From: John Ferlan To: libvir-list@redhat.com Date: Wed, 6 Sep 2017 15:24:18 -0400 Message-Id: <20170906192418.32358-1-jferlan@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] storage: Check and possibly update config file after build 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: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 06 Sep 2017 19:24:33 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" https://bugzilla.redhat.com/show_bug.cgi?id=3D1464313 As it turns out, the on-disk config file (e.g. not the stateDir file) needs to be updated when --override is provided since it's possible and highly probable that the def->source.format has been adjusted and could cause a future start after perhaps a libvirtd restart to have the older format from a define operation from the backend. So in the 2 places where it's possible a write would be needed (create after define and build), let's perform a check and do the save/write operation on the configFile if it's necessary. Signed-off-by: John Ferlan --- src/storage/storage_driver.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 7cf5943..afb0404 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -651,6 +651,22 @@ storagePoolIsPersistent(virStoragePoolPtr pool) } =20 =20 +/* After a pool build, it's possible the inactive configFile needs to + * be updated especially since overwriting the pool more than likely + * changes the source format and may change/update a few other fields. */ +static int +storagePoolBuildCheckUpdateConfig(virStoragePoolObjPtr obj, + unsigned int flags) +{ + int ret =3D 0; + + if ((flags & VIR_STORAGE_POOL_BUILD_OVERWRITE) && obj->configFile) + ret =3D virStoragePoolSaveConfig(obj->configFile, obj->def); + + return ret; +} + + static virStoragePoolPtr storagePoolCreateXML(virConnectPtr conn, const char *xml, @@ -916,6 +932,9 @@ storagePoolCreate(virStoragePoolPtr pool, if (backend->buildPool(pool->conn, obj, build_flags) < 0) goto cleanup; } + + if (storagePoolBuildCheckUpdateConfig(obj, build_flags) < 0) + goto cleanup; } =20 VIR_INFO("Starting up storage pool '%s'", obj->def->name); @@ -980,6 +999,10 @@ storagePoolBuild(virStoragePoolPtr pool, if (backend->buildPool && backend->buildPool(pool->conn, obj, flags) < 0) goto cleanup; + + if (storagePoolBuildCheckUpdateConfig(obj, flags) < 0) + goto cleanup; + ret =3D 0; =20 cleanup: --=20 2.9.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list