On Jan 5, 2008, at 10:18 AM, The Swedish Chef wrote:
> Hello all,
>
> I have been testing the COMSTAR system and so far it has worked out
> great as a high performance fc storage subsystem. I am having a
> few problems with LUN deletion as well as masking, maybe someone
> can shed some light on what I am doing wrong here.
>
> x86 OpenSolaris (SunOS san0 5.11 snv_78 i86pc i386 i86pc) is the
> target using a dual port QLE2462, the initiators are ESX Server 3.5
> with dual port QLA2342 cards.
>
> I have created LUN0 using the process described with mkfile. I
> have registered the LU and added a view which exports it to all
> initiators, and after a rescan on the ESX host the LU is discovered
> no problem. Everything works fine, the bandwidth and performance
> is excellent and I can prepare LUN0 with a VMFS filesystem.
Thats good to hear.
>
> However, when I go to create LUN1 using the exact same process,
> only a single LU shows up after rescanning the fabric, which is the
> initial LU created above. Only the first LU that is created and
> exported can be seen by any initiator for some reason, no matter
> how many additional LUs I create. I don't think this is a zoning
> issue as the switch is wide open and everything is exported with a
> default add-view, what am I doing wrong here so that only one LU is
> available?
If any LU was registered with stmf and a view entry was successfully
added, it should show up on the initiator. Can you send me the output
of stmfadm list-lu -v ?
>
> bash-3.2# sbdadm lu-list
>
> Found 3 LU(s)
>
> GUID DATA SIZE SOURCE
> -------------------------------- ------------- ----------------
> 6000ae40fe0000000000477fc3990003 2147418112 lun1
> 6000ae40fe0000000000477f38860002 107374116864 lun0
> 6000ae40fe0000000000477f26b50001 107374116864 lun0
> bash-3.2# stmfadm list-view -l 6000ae40fe0000000000477fc3990003
> View Entry: 0
> Host group : All
> Target group : All
> LUN : 1
> bash-3.2# stmfadm list-view -l 6000ae40fe0000000000477f38860002
> View Entry: 0
> Host group : All
> Target group : All
> LUN : 0
>
> Also, what is the exact process used to delete a LU after its been
> created,
Just like exporting an LU involves registering it with stmf and
adding a view entry, deleting the LU involves removing the view entry
and then de-registering the LU. When you remove the view entry, and
it was the last view entry, the LU gets removed from the
configuration database of stmf. Then you can de-register the LU from
sbd using sbdadm: sbdadm lu-deregister <GUID>
>
> For some reason the previous LU I created still has a GUID entry
> that I can't get rid of, and these GUIDs still persist even after
> doing a pkgrm and pkgadd using the process described in the
> documentation.
There was a bug in the packaging script which can cause that issue.
We are getting ready to release the new SUNWstmf package with a bunch
of new features and several bug fixes. I should send you the new
package. In the meantime. Follow these steps to completely remove
stmf so that you can pkgadd and start from fresh:
# svcadm disable stmf
# rem_drv qlt
# rem_drv fct
# rem_drv sbd
# rem_drv stmf
# svccfg delete -f stmf
# reboot
Thanks
Sumit
>
> Any help would be greatly appreciated!
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
