On Mon, Dec 1, 2014 at 5:30 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
On Mon, Dec 1, 2014 at 5:26 PM, Chris Adams <cma(a)cmadams.net>
wrote:
> Once upon a time, Gianluca Cecchi <gianluca.cecchi(a)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(a)cmadams.net>
> _______________________________________________
> Users mailing list
> Users(a)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