On Mon, Dec 1, 2014 at 5:30 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Mon, Dec 1, 2014 at 5:26 PM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Gianluca Cecchi <gianluca.cecchi@gmail.com> said:
Am I missing anyting simple?
Yep...
On the server offering iSCSI target: # tgtadm --lld iscsi --mode target --op show Target 1: iqn.2014-07.local.localdomain:store1 LUN: 1 SCSI ID: p_iscsi_store1_l LUN: 2 SCSI ID: p_iscsi_store1_l
Both LUNs have the same ID name, which confuses discovery (I've done the same thing before). This is a 16 character string, so make sure they are distinct/unique in that 16 characters.
It is annoying that scsi-target-utils lets you do this. -- Chris Adams <cma@cmadams.net> _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Arghhh! Actually the name I used is p_iscsi_store1_lun1 p_iscsi_store1_lun2
and the problem so should be that it is trimmed to 16 chars... I will try
Thanks!!
The original problem actually was to configure a new iSCSI lun for VMware on the same store provided by scsi-target-utils and this new lun was not visible... So I tried originating with oVirt to crosscheck.... Now, after changing the ID, I have # tgtadm --lld iscsi --mode target --op show | grep "SCSI ID" SCSI ID: IET 00010000 SCSI ID: p_iscsi_store1_l SCSI ID: p_lun2_istore1 and the result is that VMware is able to see the new lun ;-) But the same didn't originate any change at oVirt side: the discovery, with and without chap selected (see this thread that should be solved in my version that is 3.5: http://lists.ovirt.org/pipermail/users/2014-September/027388.html) doesn't show the new LUN to attach, only LUN 1... Any log or tes I can provide to debug problem of oVirt discovery? Gianluca