From nobody Sun May 5 09:44:39 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1551884480190390.58089661544216; Wed, 6 Mar 2019 07:01:20 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 28CF580472; Wed, 6 Mar 2019 15:01:18 +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 D4E4D1001DCA; Wed, 6 Mar 2019 15:01:17 +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 387801819AFB; Wed, 6 Mar 2019 15:01:17 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x26ExQni009281 for ; Wed, 6 Mar 2019 09:59:26 -0500 Received: by smtp.corp.redhat.com (Postfix) id C47516B485; Wed, 6 Mar 2019 14:59:26 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4962A6B483 for ; Wed, 6 Mar 2019 14:59:24 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Wed, 6 Mar 2019 15:59:11 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 1/8] iscsi_direct: Make virStorageBackendISCSIDirectGetLun report error properly 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: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 06 Mar 2019 15:01:18 +0000 (UTC) Content-Type: text/plain; charset="utf-8" This function reports error for one of the two error paths. This is unfortunate as a caller see this function failing but doesn't know right away if an error was reported. Signed-off-by: Michal Privoznik Reviewed-by: Pavel Hrdina --- src/storage/storage_backend_iscsi_direct.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/src/storage/storage_backend_iscsi_direct.c b/src/storage/stora= ge_backend_iscsi_direct.c index 786663534d..fc3b6550f7 100644 --- a/src/storage/storage_backend_iscsi_direct.c +++ b/src/storage/storage_backend_iscsi_direct.c @@ -605,22 +605,16 @@ static int virStorageBackendISCSIDirectGetLun(virStorageVolDefPtr vol, int *lun) { - const char *name =3D vol->name; - int ret =3D -1; + const char *name; =20 - if (!STRPREFIX(name, VOL_NAME_PREFIX)) { + if (!(name =3D STRSKIP(vol->name, VOL_NAME_PREFIX)) || + virStrToLong_i(name, NULL, 10, lun) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, - _("Invalid volume name %s"), name); - goto cleanup; + _("Invalid volume name %s"), vol->name); + return -1; } =20 - name +=3D strlen(VOL_NAME_PREFIX); - if (virStrToLong_i(name, NULL, 10, lun) < 0) - goto cleanup; - - ret =3D 0; - cleanup: - return ret; + return 0; } =20 static int --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 5 09:44:39 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1551884482850886.9423270168601; Wed, 6 Mar 2019 07:01:22 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C0301C05D3F4; Wed, 6 Mar 2019 15:01:20 +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 9343734D4F; Wed, 6 Mar 2019 15:01:20 +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 19830181A12A; Wed, 6 Mar 2019 15:01:20 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x26ExRwp009289 for ; Wed, 6 Mar 2019 09:59:27 -0500 Received: by smtp.corp.redhat.com (Postfix) id 9C6E76B485; Wed, 6 Mar 2019 14:59:27 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1FEDC6B483 for ; Wed, 6 Mar 2019 14:59:26 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Wed, 6 Mar 2019 15:59:12 +0100 Message-Id: <14cc0d555430d2e864c49efbbbd5d175d7165d37.1551884250.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 2/8] storage_backend_iscsi_direct: Simplify vol zeroing 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: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 06 Mar 2019 15:01:21 +0000 (UTC) Content-Type: text/plain; charset="utf-8" So far we have two branches: either we zero BLOCK_PER_PACKET (currently 128) block at one, or if we're close to the last block then we zero out one block at the time. This is very suboptimal. We know how many block are there left. Might as well just write them all at once. Also, SCSI protocol has WRITESAME command which allows us to write a single buffer multiple times. This means, that we have to transfer the buffer far less frequently and have the destination write it over and over again. Ideally, we would allocate a buffer with size equivalent to block size of the LUN and then write it as many times as there are blocks on the LUN. Sadly, this works well in theory but in practise I've found out that it's possible to write only 4096 blocks at once. Any higher value leads to a failure. But still better than Twili^Wwhat we have now. Since 4096 seems like an arbitrary number, I'm also implementing a mechanism that exponentially decreases the number of blocks we're trying to write at once. It starts at 4096 blocks and if that's too much the number is halved, and so on. Signed-off-by: Michal Privoznik --- src/storage/storage_backend_iscsi_direct.c | 55 ++++++++++++++++------ 1 file changed, 41 insertions(+), 14 deletions(-) diff --git a/src/storage/storage_backend_iscsi_direct.c b/src/storage/stora= ge_backend_iscsi_direct.c index fc3b6550f7..0af7adf32c 100644 --- a/src/storage/storage_backend_iscsi_direct.c +++ b/src/storage/storage_backend_iscsi_direct.c @@ -39,9 +39,11 @@ =20 #define ISCSI_DEFAULT_TARGET_PORT 3260 #define VIR_ISCSI_TEST_UNIT_TIMEOUT 30 * 1000 -#define BLOCK_PER_PACKET 128 #define VOL_NAME_PREFIX "unit:0:0:" =20 +/* Empirically tested to be the highest value to work without any error. */ +#define WIPE_BLOCKS_AT_ONCE 4096 + VIR_LOG_INIT("storage.storage_backend_iscsi_direct"); =20 static struct iscsi_context * @@ -624,6 +626,7 @@ virStorageBackendISCSIDirectVolWipeZero(virStorageVolDe= fPtr vol, uint64_t lba =3D 0; uint32_t block_size; uint64_t nb_block; + uint64_t wipe_at_once =3D WIPE_BLOCKS_AT_ONCE; struct scsi_task *task =3D NULL; int lun =3D 0; int ret =3D -1; @@ -635,25 +638,49 @@ virStorageBackendISCSIDirectVolWipeZero(virStorageVol= DefPtr vol, return ret; if (virISCSIDirectGetVolumeCapacity(iscsi, lun, &block_size, &nb_block= )) return ret; - if (VIR_ALLOC_N(data, block_size * BLOCK_PER_PACKET)) + if (VIR_ALLOC_N(data, block_size)) return ret; =20 + VIR_DEBUG("Starting zeroing of lun=3D%d block_size=3D%ju nb_block=3D%j= u wipe_at_once=3D%ju", + lun, (uintmax_t) block_size, (uintmax_t) nb_block, (uintmax_= t) wipe_at_once); + while (lba < nb_block) { - if (nb_block - lba > block_size * BLOCK_PER_PACKET) { + const uint64_t to_write =3D MIN(nb_block - lba + 1, wipe_at_once); + bool fail =3D false; =20 - if (!(task =3D iscsi_write16_sync(iscsi, lun, lba, data, - block_size * BLOCK_PER_PACKET, - block_size, 0, 0, 0, 0, 0))) - return -1; - scsi_free_scsi_task(task); - lba +=3D BLOCK_PER_PACKET; - } else { - if (!(task =3D iscsi_write16_sync(iscsi, lun, lba, data, block= _size, - block_size, 0, 0, 0, 0, 0))) - return -1; + if (!(task =3D iscsi_writesame16_sync(iscsi, lun, lba, + data, block_size, + to_write, + 0, 0, 0, 0))) + fail =3D true; + + if (task && + task->status =3D=3D SCSI_STATUS_CHECK_CONDITION && + task->sense.key =3D=3D SCSI_SENSE_ILLEGAL_REQUEST && + task->sense.ascq =3D=3D SCSI_SENSE_ASCQ_INVALID_FIELD_IN_CDB) { + /* This means that we tried to write too much blocks at once. + * Halve it (if it's not small enough already) and retry. */ + if (wipe_at_once > 1) { + wipe_at_once /=3D 2; + VIR_DEBUG("Halving wipe_at_once to %ju", (uintmax_t) wipe_= at_once); + scsi_free_scsi_task(task); + continue; + } + + fail =3D true; + } + + if (fail) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("failed to run writesame: %s"), + iscsi_get_error(iscsi)); scsi_free_scsi_task(task); - lba++; + return -1; } + + scsi_free_scsi_task(task); + + lba +=3D to_write; } =20 return 0; --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 5 09:44:39 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 155188450952310.383904579970817; Wed, 6 Mar 2019 07:01:49 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A0A02306DBBB; Wed, 6 Mar 2019 15:01:47 +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 782A27F1D5; Wed, 6 Mar 2019 15:01:47 +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 2E5D1181A048; Wed, 6 Mar 2019 15:01:47 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x26ExSqg009301 for ; Wed, 6 Mar 2019 09:59:28 -0500 Received: by smtp.corp.redhat.com (Postfix) id 713DE6B47E; Wed, 6 Mar 2019 14:59:28 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id EB43E6B483 for ; Wed, 6 Mar 2019 14:59:27 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Wed, 6 Mar 2019 15:59:13 +0100 Message-Id: <83b89dc4760301966291580a6f68b25adf2aa0fc.1551884250.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 3/8] iscsi_direct: Don't overwrite error in virStorageBackenISCSIDirectWipeVol() 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: , 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.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Wed, 06 Mar 2019 15:01:48 +0000 (UTC) Content-Type: text/plain; charset="utf-8" If virStorageBackendISCSIDirectVolWipeZero() fails, it has already reported an error which is probably specific enough. Do not overwrite it with some generic one. Signed-off-by: Michal Privoznik Reviewed-by: Pavel Hrdina --- src/storage/storage_backend_iscsi_direct.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/storage/storage_backend_iscsi_direct.c b/src/storage/stora= ge_backend_iscsi_direct.c index 0af7adf32c..613c38e225 100644 --- a/src/storage/storage_backend_iscsi_direct.c +++ b/src/storage/storage_backend_iscsi_direct.c @@ -706,12 +706,8 @@ virStorageBackenISCSIDirectWipeVol(virStoragePoolObjPt= r pool, =20 switch ((virStorageVolWipeAlgorithm) algorithm) { case VIR_STORAGE_VOL_WIPE_ALG_ZERO: - if (virStorageBackendISCSIDirectVolWipeZero(vol, iscsi) < 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("failed to wipe volume %s"), - vol->name); + if (virStorageBackendISCSIDirectVolWipeZero(vol, iscsi) < 0) goto cleanup; - } break; case VIR_STORAGE_VOL_WIPE_ALG_TRIM: case VIR_STORAGE_VOL_WIPE_ALG_NNSA: --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 5 09:44:39 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1551884513316221.70214459688134; Wed, 6 Mar 2019 07:01:53 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A42503087BA8; Wed, 6 Mar 2019 15:01:51 +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 73D1C60151; Wed, 6 Mar 2019 15:01:51 +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 2BD55181A136; Wed, 6 Mar 2019 15:01:51 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x26ExTGA009314 for ; Wed, 6 Mar 2019 09:59:29 -0500 Received: by smtp.corp.redhat.com (Postfix) id 48FF86B481; Wed, 6 Mar 2019 14:59:29 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id C1A816B47E for ; Wed, 6 Mar 2019 14:59:28 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Wed, 6 Mar 2019 15:59:14 +0100 Message-Id: <0084c60ac88c7ca4bb7a19392cf9c8907c4801df.1551884250.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 4/8] virISCSIDirectReportLuns: Drop ClearVols 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: , 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Wed, 06 Mar 2019 15:01:52 +0000 (UTC) Content-Type: text/plain; charset="utf-8" In bf5cf610f206d5d54 I've fixed a problem where iscsi-direct backend was reporting only the last LUN. The fix consisted of moving virStoragePoolObjClearVols() one level up. However, as it turns out, storage driver already calls it before calling refreshPool callback (which is virStorageBackendISCSIDirectRefreshPool() in this case). Signed-off-by: Michal Privoznik Reviewed-by: Pavel Hrdina --- src/storage/storage_backend_iscsi_direct.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/storage/storage_backend_iscsi_direct.c b/src/storage/stora= ge_backend_iscsi_direct.c index 613c38e225..1f33fadad9 100644 --- a/src/storage/storage_backend_iscsi_direct.c +++ b/src/storage/storage_backend_iscsi_direct.c @@ -377,7 +377,6 @@ virISCSIDirectReportLuns(virStoragePoolObjPtr pool, =20 def->capacity =3D 0; def->allocation =3D 0; - virStoragePoolObjClearVols(pool); for (i =3D 0; i < list->num; i++) { if (virISCSIDirectRefreshVol(pool, iscsi, list->luns[i], portal) <= 0) goto cleanup; --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 5 09:44:39 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1551884486967589.8726684947593; Wed, 6 Mar 2019 07:01:26 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 520FB3001572; Wed, 6 Mar 2019 15:01:24 +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 211A3692B5; Wed, 6 Mar 2019 15:01:24 +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 C4585181A137; Wed, 6 Mar 2019 15:01:23 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x26ExX0k009333 for ; Wed, 6 Mar 2019 09:59:33 -0500 Received: by smtp.corp.redhat.com (Postfix) id C6DCD6B483; Wed, 6 Mar 2019 14:59:33 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4B9146B481 for ; Wed, 6 Mar 2019 14:59:29 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Wed, 6 Mar 2019 15:59:15 +0100 Message-Id: <7e030b627fcdbe6be4cb293cbfccd038d39d637a.1551884250.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 5/8] storageVolWipePattern: Don't take shortcut to refreshPool() 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: , 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.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Wed, 06 Mar 2019 15:01:25 +0000 (UTC) Content-Type: text/plain; charset="utf-8" In d16f803d780 we've tried to solve an issue that after wiping an image its format might have changed (e.g. from qcow2 to raw) but libvirt wasn't probing the image format. We fixed this by calling virStorageBackendRefreshVolTargetUpdate() which is what refreshPool() would end up calling. But this shortcut is not good enough because the function is called only for local types of volumes (like dir, fs, netfs). But now that more backends support volume wiping we have to call the function with more caution. Signed-off-by: Michal Privoznik --- src/storage/storage_driver.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 98be434005..cefffdfd64 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2525,11 +2525,15 @@ storageVolWipePattern(virStorageVolPtr vol, if (rc < 0) goto cleanup; =20 - /* Instead of using the refreshVol, since much changes on the target - * volume, let's update using the same function as refreshPool would - * use when it discovers a volume. The only failure to capture is -1, - * we can ignore -2. */ - if (virStorageBackendRefreshVolTargetUpdate(voldef) =3D=3D -1) + /* For local volumes, Instead of using the refreshVol, since + * much changes on the target volume, let's update using the + * same function as refreshPool would use when it discovers a + * volume. The only failure to capture is -1, we can ignore + * -2. */ + if ((backend->type =3D=3D VIR_STORAGE_POOL_DIR || + backend->type =3D=3D VIR_STORAGE_POOL_FS || + backend->type =3D=3D VIR_STORAGE_POOL_NETFS) && + virStorageBackendRefreshVolTargetUpdate(voldef) =3D=3D -1) goto cleanup; =20 ret =3D 0; --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 5 09:44:39 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1551884490579192.4545573393683; Wed, 6 Mar 2019 07:01:30 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C9B642D7E7; Wed, 6 Mar 2019 15:01:28 +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 961BD6ACEE; Wed, 6 Mar 2019 15:01:28 +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 476D5181A138; Wed, 6 Mar 2019 15:01:28 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x26ExYv4009338 for ; Wed, 6 Mar 2019 09:59:34 -0500 Received: by smtp.corp.redhat.com (Postfix) id 9D2186B48E; Wed, 6 Mar 2019 14:59:34 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 21B256B481 for ; Wed, 6 Mar 2019 14:59:33 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Wed, 6 Mar 2019 15:59:16 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 6/8] storage_driver: Introduce storagePoolRefreshImpl() 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: , 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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 06 Mar 2019 15:01:29 +0000 (UTC) Content-Type: text/plain; charset="utf-8" This is a wrapper over refreshPool() call as at all places we are doing basically the same. Might as well have a single function to call. Signed-off-by: Michal Privoznik Reviewed-by: Pavel Hrdina --- src/storage/storage_driver.c | 61 +++++++++++++++++++----------------- 1 file changed, 32 insertions(+), 29 deletions(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index cefffdfd64..8cb3c40e51 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -92,6 +92,21 @@ storagePoolRefreshFailCleanup(virStorageBackendPtr backe= nd, } =20 =20 +static int +storagePoolRefreshImpl(virStorageBackendPtr backend, + virStoragePoolObjPtr obj, + const char *stateFile) +{ + virStoragePoolObjClearVols(obj); + if (backend->refreshPool(obj) < 0) { + storagePoolRefreshFailCleanup(backend, obj, stateFile); + return -1; + } + + return 0; +} + + /** * virStoragePoolUpdateInactive: * @poolptr: pointer to a variable holding the pool object pointer @@ -148,15 +163,12 @@ storagePoolUpdateStateCallback(virStoragePoolObjPtr o= bj, * it anyway, but if they do and fail, we want to log error and * continue with other pools. */ - if (active) { - virStoragePoolObjClearVols(obj); - if (backend->refreshPool(obj) < 0) { - storagePoolRefreshFailCleanup(backend, obj, stateFile); - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Failed to restart storage pool '%s': %s"), - def->name, virGetLastErrorMessage()); - active =3D false; - } + if (active && + storagePoolRefreshImpl(backend, obj, stateFile) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to restart storage pool '%s': %s"), + def->name, virGetLastErrorMessage()); + active =3D false; } =20 virStoragePoolObjSetActive(obj, active); @@ -203,12 +215,10 @@ storageDriverAutostartCallback(virStoragePoolObjPtr o= bj, if (started) { VIR_AUTOFREE(char *) stateFile =3D NULL; =20 - virStoragePoolObjClearVols(obj); stateFile =3D virFileBuildPath(driver->stateDir, def->name, ".xml"= ); if (!stateFile || virStoragePoolSaveState(stateFile, def) < 0 || - backend->refreshPool(obj) < 0) { - storagePoolRefreshFailCleanup(backend, obj, stateFile); + storagePoolRefreshImpl(backend, obj, stateFile) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to autostart storage pool '%s': %s"), def->name, virGetLastErrorMessage()); @@ -721,10 +731,9 @@ storagePoolCreateXML(virConnectPtr conn, =20 stateFile =3D virFileBuildPath(driver->stateDir, def->name, ".xml"); =20 - virStoragePoolObjClearVols(obj); - if (!stateFile || virStoragePoolSaveState(stateFile, def) < 0 || - backend->refreshPool(obj) < 0) { - storagePoolRefreshFailCleanup(backend, obj, stateFile); + if (!stateFile || + virStoragePoolSaveState(stateFile, def) < 0 || + storagePoolRefreshImpl(backend, obj, stateFile) < 0) { goto error; } =20 @@ -916,10 +925,9 @@ storagePoolCreate(virStoragePoolPtr pool, =20 stateFile =3D virFileBuildPath(driver->stateDir, def->name, ".xml"); =20 - virStoragePoolObjClearVols(obj); - if (!stateFile || virStoragePoolSaveState(stateFile, def) < 0 || - backend->refreshPool(obj) < 0) { - storagePoolRefreshFailCleanup(backend, obj, stateFile); + if (!stateFile || + virStoragePoolSaveState(stateFile, def) < 0 || + storagePoolRefreshImpl(backend, obj, stateFile) < 0) { goto cleanup; } =20 @@ -1116,6 +1124,7 @@ storagePoolRefresh(virStoragePoolPtr pool, virStoragePoolObjPtr obj; virStoragePoolDefPtr def; virStorageBackendPtr backend; + VIR_AUTOFREE(char *) stateFile =3D NULL; int ret =3D -1; virObjectEventPtr event =3D NULL; =20 @@ -1144,13 +1153,8 @@ storagePoolRefresh(virStoragePoolPtr pool, goto cleanup; } =20 - virStoragePoolObjClearVols(obj); - if (backend->refreshPool(obj) < 0) { - VIR_AUTOFREE(char *) stateFile =3D NULL; - - stateFile =3D virFileBuildPath(driver->stateDir, def->name, ".xml"= ); - storagePoolRefreshFailCleanup(backend, obj, stateFile); - + stateFile =3D virFileBuildPath(driver->stateDir, def->name, ".xml"); + if (storagePoolRefreshImpl(backend, obj, stateFile) < 0) { event =3D virStoragePoolEventLifecycleNew(def->name, def->uuid, VIR_STORAGE_POOL_EVENT_STO= PPED, @@ -2240,8 +2244,7 @@ virStorageVolPoolRefreshThread(void *opaque) if (!(backend =3D virStorageBackendForType(def->type))) goto cleanup; =20 - virStoragePoolObjClearVols(obj); - if (backend->refreshPool(obj) < 0) + if (storagePoolRefreshImpl(backend, obj, NULL) < 0) VIR_DEBUG("Failed to refresh storage pool"); =20 event =3D virStoragePoolEventRefreshNew(def->name, def->uuid); --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 5 09:44:39 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1551884491186339.6770284133378; Wed, 6 Mar 2019 07:01:31 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7903C81F19; Wed, 6 Mar 2019 15:01:29 +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 4B6761001DCC; Wed, 6 Mar 2019 15:01:29 +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 012B83D389; Wed, 6 Mar 2019 15:01:28 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x26ExbC6009358 for ; Wed, 6 Mar 2019 09:59:37 -0500 Received: by smtp.corp.redhat.com (Postfix) id 05FD26B485; Wed, 6 Mar 2019 14:59:37 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7DC646B481 for ; Wed, 6 Mar 2019 14:59:34 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Wed, 6 Mar 2019 15:59:17 +0100 Message-Id: <38449540b4d119a85653a2e88771ea5ad26ef65e.1551884250.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 7/8] storagePoolRefreshFailCleanup: Clear volumes on failed refresh 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: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 06 Mar 2019 15:01:30 +0000 (UTC) Content-Type: text/plain; charset="utf-8" If pool refresh failed, then the internal table of volumes is probably left in inconsistent or incomplete state anyways. Clear it out then. This has an advantage that we can move the virStoragePoolObjClearVols() from those very few backends that do call it. Signed-off-by: Michal Privoznik Reviewed-by: Pavel Hrdina --- src/storage/storage_backend_gluster.c | 2 -- src/storage/storage_backend_logical.c | 12 +++--------- src/storage/storage_backend_rbd.c | 4 +--- src/storage/storage_driver.c | 2 ++ src/storage/storage_util.c | 2 -- 5 files changed, 6 insertions(+), 16 deletions(-) diff --git a/src/storage/storage_backend_gluster.c b/src/storage/storage_ba= ckend_gluster.c index 819993439a..5955d834d9 100644 --- a/src/storage/storage_backend_gluster.c +++ b/src/storage/storage_backend_gluster.c @@ -402,8 +402,6 @@ virStorageBackendGlusterRefreshPool(virStoragePoolObjPt= r pool) if (dir) glfs_closedir(dir); virStorageBackendGlusterClose(state); - if (ret < 0) - virStoragePoolObjClearVols(pool); return ret; } =20 diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_ba= ckend_logical.c index 77e4dfb8b1..83b5f27151 100644 --- a/src/storage/storage_backend_logical.c +++ b/src/storage/storage_backend_logical.c @@ -760,14 +760,13 @@ virStorageBackendLogicalRefreshPool(virStoragePoolObj= Ptr pool) 2 }; virStoragePoolDefPtr def =3D virStoragePoolObjGetDef(pool); - int ret =3D -1; VIR_AUTOPTR(virCommand) cmd =3D NULL; =20 virWaitForDevices(); =20 /* Get list of all logical volumes */ if (virStorageBackendLogicalFindLVs(pool, NULL) < 0) - goto cleanup; + return -1; =20 cmd =3D virCommandNewArgList(VGS, "--separator", ":", @@ -788,14 +787,9 @@ virStorageBackendLogicalRefreshPool(virStoragePoolObjP= tr pool) pool, "vgs", NULL) < 0) - goto cleanup; + return -1; =20 - ret =3D 0; - - cleanup: - if (ret < 0) - virStoragePoolObjClearVols(pool); - return ret; + return 0; } =20 /* diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backen= d_rbd.c index 2b7af1db23..3eae780c44 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -648,10 +648,8 @@ virStorageBackendRBDRefreshPool(virStoragePoolObjPtr p= ool) goto cleanup; } =20 - if (virStoragePoolObjAddVol(pool, vol) < 0) { - virStoragePoolObjClearVols(pool); + if (virStoragePoolObjAddVol(pool, vol) < 0) goto cleanup; - } vol =3D NULL; } =20 diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 8cb3c40e51..fee1220b53 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -81,6 +81,8 @@ storagePoolRefreshFailCleanup(virStorageBackendPtr backen= d, { virErrorPtr orig_err =3D virSaveLastError(); =20 + virStoragePoolObjClearVols(obj); + if (stateFile) unlink(stateFile); if (backend->stopPool) diff --git a/src/storage/storage_util.c b/src/storage/storage_util.c index 7a879b0f46..62f857f9ea 100644 --- a/src/storage/storage_util.c +++ b/src/storage/storage_util.c @@ -3620,8 +3620,6 @@ virStorageBackendRefreshLocal(virStoragePoolObjPtr po= ol) ret =3D 0; cleanup: VIR_DIR_CLOSE(dir); - if (ret < 0) - virStoragePoolObjClearVols(pool); return ret; } =20 --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sun May 5 09:44:39 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1551884495197937.424882666672; Wed, 6 Mar 2019 07:01:35 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 86CDA88305; Wed, 6 Mar 2019 15:01:33 +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 5ED626AD02; Wed, 6 Mar 2019 15:01:33 +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 0DBB1181A13D; Wed, 6 Mar 2019 15:01:33 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x26Exbi6009371 for ; Wed, 6 Mar 2019 09:59:37 -0500 Received: by smtp.corp.redhat.com (Postfix) id CF82F6B48F; Wed, 6 Mar 2019 14:59:37 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 546536B481 for ; Wed, 6 Mar 2019 14:59:37 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Wed, 6 Mar 2019 15:59:18 +0100 Message-Id: <9ccfaea96e2b3fb2b3adcfe38e14591676554c90.1551884250.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 8/8] virsh-pool: Offer only active pool for pool-refresh completer 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: , 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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 06 Mar 2019 15:01:34 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Only active pools can be refreshed. But our completer offers just all pool, even inactive ones. Signed-off-by: Michal Privoznik Reviewed-by: Pavel Hrdina --- tools/virsh-pool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virsh-pool.c b/tools/virsh-pool.c index d98fd80330..f641f5776c 100644 --- a/tools/virsh-pool.c +++ b/tools/virsh-pool.c @@ -735,7 +735,7 @@ static const vshCmdInfo info_pool_refresh[] =3D { }; =20 static const vshCmdOptDef opts_pool_refresh[] =3D { - VIRSH_COMMON_OPT_POOL_FULL(0), + VIRSH_COMMON_OPT_POOL_FULL(VIR_CONNECT_LIST_STORAGE_POOLS_ACTIVE), =20 {.name =3D NULL} }; --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list