Description of problem: Only list one volume info even though has multiple luns for iscsi-direct pool Version-Release number of selected component (if applicable): libvirt-4.10.0-1.module+el8+2317+367e35b5.x86_64 qemu-kvm-3.0.0-2.module+el8+2246+78080371.x86_64 How reproducible: 100% Steps to Reproduce: 1. Prepare a target server: # targetcli ls o- iqn.2017-12.com.virttest:emulated-iscsi-noauth.target2 .......... [TPGs: 1] | o-tpg1 .............................................. [gen-acls, no-auth] | o- acls .................................................. [ACLs: 0] | o- luns ..................................................... [LUNs: 2] | | o- lun0 ............ [fileio/file1 (/var/lib/libvirt/images/test.img) (default_tg_pt_gp)] | | o- lun1 ....... [fileio/file3 (/var/lib/libvirt/images/lmn.qcow2) (default_tg_pt_gp)] | o- portals ............................................ [Portals: 1] | o- 10.66.144.87:3260 .............................. [OK] 2. Create icsi-direct pool in client. # virsh pool-create iscsi-direct.xml # virsh pool-dumpxml iscsi-direct <pool type='iscsi-direct'> <name>iscsi-direct</name> <uuid>0799697a-94dd-4115-9601-8714b1931248</uuid> <capacity unit='bytes'>524287488</capacity> <allocation unit='bytes'>524287488</allocation> <available unit='bytes'>0</available> <source> <host name='10.66.144.87'/> <device path='iqn.2017-12.com.virttest:emulated-iscsi-noauth.target2'/> <initiator> <iqn name='iqn.2017-12.com.example:client'/> </initiator> </source> </pool> 3. Check volume info. # virsh vol-list iscsi-direct Name Path ----------------------------------------------------------------------- unit:0:0:1 ip-10.66.144.87:3260-iscsi-iqn.2017-12.com.virttest:emulated-iscsi-noauth.target2-lun-1 Actual results: As step3, only list one volume info Expected results: Should list all of the volumes created in that iscsi target Additional info:
It can be listed by libiscsi-tools: # iscsi-ls --show-luns iscsi://10.66.144.87 Target:iqn.2017-12.com.virttest:emulated-iscsi-noauth.target2 Portal:10.66.144.87:3260,1 Lun:0 Type:DIRECT_ACCESS (Size:299M) Lun:1 Type:DIRECT_ACCESS (Size:1G) It's likely a bug of libvirt.
This is already fixed upstream by commit bf5cf610f206d5d54914e8f8b0764b2b37ddf50c Refs: v5.1.0-rc2-4-gbf5cf610f2 Author: Michal Privoznik <mprivozn> AuthorDate: Thu Feb 28 15:08:19 2019 +0100 Commit: Michal Privoznik <mprivozn> CommitDate: Thu Feb 28 15:55:48 2019 +0100 virISCSIDirectRefreshVol: Don't clear volumes in each run When fetching LUNs from iscsi server the virISCSIDirectReportLuns() is called. This function does some libiscsi calls and then calls virISCSIDirectRefreshVol() over each LUN found. It's unfortunate that the latter calls virStoragePoolObjClearVols() as we lose all LUNs processed in previous iterations. Signed-off-by: Michal Privoznik <mprivozn> Reviewed-by: Jiri Denemark <jdenemar>
Verified Version: libvirt-5.4.0-1.module+el8.1.0+3304+7eb41d5f.x86_64 qemu-kvm-4.0.0-4.module+el8.1.0+3356+cda7f1ee.x86_64 kernel-4.18.0-107.el8.x86_64 Verified Steps: 1. Define and start an iscsi-direct pool. # virsh pool-dumpxml iscsi-direct <pool type='iscsi-direct'> <name>iscsi-direct</name> <uuid>2b621385-f734-4b98-8131-0fc17ed29e67</uuid> <capacity unit='bytes'>64424704512</capacity> <allocation unit='bytes'>64424704512</allocation> <available unit='bytes'>0</available> <source> <host name='**IP**'/> <device path='iqn.2017-12.com.virttest:emulated-iscsi-noauth.target2'/> <initiator> <iqn name='iqn.2017-12.com.example:client'/> </initiator> </source> </pool> 2. Check volume info. # virsh vol-list iscsi-direct Name Path ------------------------------------------------------------------------------------------------------ unit:0:0:0 ip-**IP**:3260-iscsi-iqn.2017-12.com.virttest:emulated-iscsi-noauth.target2-lun-0 unit:0:0:1 ip-**IP**:3260-iscsi-iqn.2017-12.com.virttest:emulated-iscsi-noauth.target2-lun-1 unit:0:0:2 ip-**IP**:3260-iscsi-iqn.2017-12.com.virttest:emulated-iscsi-noauth.target2-lun-2 # virsh vol-info unit:0:0:2 iscsi-direct Name: unit:0:0:2 Type: network Capacity: 30.00 GiB Allocation: 30.00 GiB So move this bug to be verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3723