Description of problem: The LUNs list, provided during deplyment, doesn't have enough information. Currently it has the device name as it appears under /dev/ (sda, sdb..) and the size in MB. [ INFO ] Discovering iSCSI node [ INFO ] Connecting to the storage server The following luns have been found on the requested target: 1 - sdc - 51200MB 2 - sdd - 51200MB 3 - sde - 51200MB 4 - sdf - 51200MB 5 - sdg - 51200MB This list should also contain the following details: - LUN ID - Vendor ID - Path number - Product ID - Serial Version-Release number of selected component (if applicable): rhev 3.5 vt13.5
Re-targeting to 3.6 since this is an RFE. Not sure it's worth to be in 3.5.1. Scott?
Nir, looking at your comments in http://gerrit.ovirt.org/#/c/37494/1/src/plugins/ovirt-hosted-engine-setup/storage/iscsi.py,cm I think we should discuss how to change the list in this bug.
(In reply to Sandro Bonazzola from comment #2) > Nir, looking at your comments in > http://gerrit.ovirt.org/#/c/37494/1/src/plugins/ovirt-hosted-engine-setup/ > storage/iscsi.py,cm I think we should discuss how to change the list in this > bug. I provided the info in my comment: http://gerrit.ovirt.org/#/c/37494/1/src/plugins/ovirt-hosted-engine-setup/storage/iscsi.py,cm Not clear what other info you need.
(In reply to Elad from comment #0) Looks good, providing what we get in engine when you add/edit iscsi/fcp storage domain. However it will be hard to include all values in the shell, so I think we should pick only the most important items: GUID, size, vendor id and prodcut id. It will also be useful to show status of paths if some of the paths are not active. Note also that size should use G and not MB - this is the smallest unit users care about. [ INFO ] Connecting to the storage server The following luns have been found on the requested target: 1 360060160f4a030008b5463fdf56fe411 70G DGC/VRAID 7 paths active 2 360060160f4a030008b5463fdf56fe411 50G DGC/VRAID 6 paths active, 1 failed If we want all info we can do something like this: [ INFO ] Connecting to the storage server The following luns have been found on the requested target: 1 360060160f4a030008b5463fdf56fe411 70G vendor: DGC product: VRAID serial: SDGC_VRAID_CKM00121000438 status: 7 paths active 2 360060160f4a030008b5463fdf56fe411 50G vendor: DGC product: VRAID serial: SDGC_VRAID_CKM00121000439 status: 6 paths active, 1 failed I think the 2 lines compatct output is more useful, specially when you have lot of luns.
On my opinion we still need to found a way to indicate that the first number is simply an internal progressive and it's not related to the LUN number. Maybe using a letter instead of a number could be a good idea to avoid any possible confusion between the LUN number and our reference. Something like: [ INFO ] Connecting to the storage server The following luns have been found on the requested target: A 360060160f4a030008b5463fdf56fe411 70G DGC/VRAID 7 paths active B 360060160f4a030008b5463fdf56fe411 50G DGC/VRAID 6 paths active, 1 failed
(In reply to Simone Tiraboschi from comment #5) > On my opinion we still need to found a way to indicate that the first number > is simply an internal progressive and it's not related to the LUN number. > Maybe using a letter instead of a number could be a good idea to avoid any > possible confusion between the LUN number and our reference. > > Something like: > > [ INFO ] Connecting to the storage server > The following luns have been found on the requested target: > > A 360060160f4a030008b5463fdf56fe411 70G DGC/VRAID > 7 paths active > > B 360060160f4a030008b5463fdf56fe411 50G DGC/VRAID > 6 paths active, 1 failed Showing numbered list of options is very common, and I don't see why it wil confuse anyone. If you look in multipath -ll output, you can see that there is no such thing as lun number there, and I don't think users are expecting lun number. To make it even more clear we can use: [ INFO ] Connecting to the storage server The following luns have been found on the requested target: [1] 360060160f4a030008b5463fdf56fe411 70G DGC/VRAID 7 paths active [2] 360060160f4a030008b5463fdf56fe411 50G DGC/VRAID 6 paths active, 1 failed Anyway, changing the way list items are numbered is easy. The best way to choose is to get some users using this code and check if it works for them.
Automated message: can you please update doctext or set it as not required?
Tested using ovirt 3.6.0-1 on iSCSI and on FC. User gets the following information as part of the LUNs list: LUN ID, size in GB, vendor, paths and product ID: [1] 3514f0c5447601164 53GiB XtremIO XtremApp status: used, paths: 1 active
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://rhn.redhat.com/errata/RHEA-2016-0375.html