Description of problem: Import Storage Domain of block Device should also import Lun disks which reflected by the Luns without Storage Domain they are contained in them Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Try to import target of iSCSI domain 2. 3. Actual results: No Direct Lun will be found Expected results: Direct Lun should be presented when trying to discover the target they are based on, and should be registered as a disk when the user desires to Additional info:
I do not understand this BZ. You do NOT import a target - you import a domain, which should not be presented as a LUN.
(In reply to Allon Mureinik from comment #1) > I do not understand this BZ. > You do NOT import a target - you import a domain, which should not be > presented as a LUN. As described in the expected result: Direct Lun should be presented when trying to discover the target they are based on, and should be registered as a disk when the user desires to. The steps to reproduce should be: 1. Try to connect to a target contains LUN disk 2. 3.
Again - any LUN is potentially a direct LUN. How would you discover it? How would you distinguish it used to be a direct LUN?
Referring to Allon's comments at https://bugzilla.redhat.com/show_bug.cgi?id=1138121#c3, Since direct LUN is an entity which is mainly managed by the user, it is more appropriate that the user will manage direct Lun disks on a Disaster Recovery scenario by adding it directly to the setup as it is already done today when adding a Direct Lun disk. The only "gap" which had to be considered was a VM which had only direct Lun disks, and this bug was already solved (https://bugzilla.redhat.com/1138134), so this bug might not be relevant any more. Therefore closing it as Not a Bug