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