From nobody Sun Apr 28 21:54:02 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 1545173228402678.3096359553658; Tue, 18 Dec 2018 14:47:08 -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 6C81685550; Tue, 18 Dec 2018 22:47:05 +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 3F3B21E7; Tue, 18 Dec 2018 22:47:04 +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 C2653181B9E7; Tue, 18 Dec 2018 22:47:01 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id wBIMl09g028212 for ; Tue, 18 Dec 2018 17:47:00 -0500 Received: by smtp.corp.redhat.com (Postfix) id 440EA6012C; Tue, 18 Dec 2018 22:47:00 +0000 (UTC) Received: from unknown54ee7586bd10.attlocal.net.com (ovpn-117-129.phx2.redhat.com [10.3.117.129]) by smtp.corp.redhat.com (Postfix) with ESMTP id E3C0D600C9 for ; Tue, 18 Dec 2018 22:46:56 +0000 (UTC) From: John Ferlan To: libvir-list@redhat.com Date: Tue, 18 Dec 2018 17:46:53 -0500 Message-Id: <20181218224653.20286-1-jferlan@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] storage: More uniquely identify NPIV LUNs 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.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.28]); Tue, 18 Dec 2018 22:47:06 +0000 (UTC) Content-Type: text/plain; charset="utf-8" https://bugzilla.redhat.com/show_bug.cgi?id=3D1657468 Commit be1bb6c95 changed the way volumes were stored from a forward linked list to a hash table. In doing so, it required that each vol object would have 3 unique values as keys into tables - key, name, and path. Due to how vHBA/NPIV LUNs are created/used this resulted in a failure to utilize all the LUN's found during processing. The virStorageBackendSCSINewLun uses virStorageBackendSCSISerial in order to read/return the unique serial number of the LUN to be used as a key for the volume. However, for NPIV based LUNs the logic results in usage of the same serial value for each path to the LUN. For example, $ lsscsi -tg ... [4:0:3:13] disk fc:0x207800c0ffd79b2a0xeb02ef /dev/sde /dev/sg16 [4:0:4:0] disk fc:0x50060169446021980xeb1f00 /dev/sdf /dev/sg17 [4:0:5:0] disk fc:0x50060161446021980xeb2000 /dev/sdg /dev/sg18 ... /lib/udev/scsi_id --replace-whitespace --whitelisted --device /dev/sde 3600c0ff000d7a2965c603e5401000000 /lib/udev/scsi_id --replace-whitespace --whitelisted --device /dev/sdf 350060160c460219850060160c4602198 /lib/udev/scsi_id --replace-whitespace --whitelisted --device /dev/sdg 350060160c460219850060160c4602198 The /dev/sdf and /dev/sdg although separate LUNs would end up with the same serial number used for the vol->key value. When attempting to add the LUN via virStoragePoolObjAddVol, the hash table code will indicate that we have a duplicate: virHashAddOrUpdateEntry:341 : internal error: Duplicate key and thus the LUN is not added to the pool. Digging deeper into the scsi_id output using the --export option one will find that the only difference between the two luns is: ID_TARGET_PORT=3D1 for /dev/sdf ID_TARGET_PORT=3D2 for /dev/sdg So, let's use the ID_TARGET_PORT string value along with the serial to generate a more unique key using "@serial_PORT@target_port", where @target_port is just the value of the ID_TARGET_PORT for the LUN. Signed-off-by: John Ferlan --- src/storage/storage_util.c | 61 +++++++++++++++++++++++++++++++++++++- 1 file changed, 60 insertions(+), 1 deletion(-) diff --git a/src/storage/storage_util.c b/src/storage/storage_util.c index a84ee5b600..d6d441c06d 100644 --- a/src/storage/storage_util.c +++ b/src/storage/storage_util.c @@ -3755,6 +3755,49 @@ virStorageBackendRefreshLocal(virStoragePoolObjPtr p= ool) } =20 =20 +static char * +virStorageBackendSCSITargetPort(const char *dev) +{ + char *target_port =3D NULL; + const char *id; +#ifdef WITH_UDEV + virCommandPtr cmd =3D virCommandNewArgList( + "/lib/udev/scsi_id", + "--replace-whitespace", + "--whitelisted", + "--export", + "--device", dev, + NULL + ); + + /* Run the program and capture its output */ + virCommandSetOutputBuffer(cmd, &target_port); + if (virCommandRun(cmd, NULL) < 0) + goto cleanup; +#endif + + if (target_port && STRNEQ(target_port, "") && + (id =3D strstr(target_port, "ID_TARGET_PORT=3D"))) { + char *nl =3D strchr(id, '\n'); + if (nl) + *nl =3D '\0'; + id =3D strrchr(id, '=3D'); + memmove(target_port, id + 1, strlen(id)); + } else { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("unable to uniquely identify target port for '%s'= "), + dev); + } + +#ifdef WITH_UDEV + cleanup: + virCommandFree(cmd); +#endif + + return target_port; +} + + static char * virStorageBackendSCSISerial(const char *dev) { @@ -3813,6 +3856,8 @@ virStorageBackendSCSINewLun(virStoragePoolObjPtr pool, virStoragePoolDefPtr def =3D virStoragePoolObjGetDef(pool); virStorageVolDefPtr vol =3D NULL; char *devpath =3D NULL; + char *key =3D NULL; + char *target_port =3D NULL; int retval =3D -1; =20 /* Check if the pool is using a stable target path. The call to @@ -3877,9 +3922,21 @@ virStorageBackendSCSINewLun(virStoragePoolObjPtr poo= l, VIR_STORAGE_VOL_READ_NOER= ROR)) < 0) goto cleanup; =20 - if (!(vol->key =3D virStorageBackendSCSISerial(vol->target.path))) + if (!(key =3D virStorageBackendSCSISerial(vol->target.path))) goto cleanup; =20 + if (def->source.adapter.type =3D=3D VIR_STORAGE_ADAPTER_TYPE_FC_HOST && + STRNEQ(key, vol->target.path)) { + /* NPIV based LUNs use the same "serial" key. In order to distingu= ish + * we need to append a port value */ + if (!(target_port =3D virStorageBackendSCSITargetPort(vol->target.= path))) + goto cleanup; + if (virAsprintf(&vol->key, "%s_PORT%s", key, target_port) < 0) + goto cleanup; + } else { + VIR_STEAL_PTR(vol->key, key); + } + def->capacity +=3D vol->target.capacity; def->allocation +=3D vol->target.allocation; =20 @@ -3892,6 +3949,8 @@ virStorageBackendSCSINewLun(virStoragePoolObjPtr pool, cleanup: virStorageVolDefFree(vol); VIR_FREE(devpath); + VIR_FREE(target_port); + VIR_FREE(key); return retval; } =20 --=20 2.17.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list