the key thing here was the issue of mapping. snapdrive saw them but could do nothing else.
you can create the luns via the command line, just do not map them. or if you use lun setup, unmap them after you create them
-- Daniel Leeds Manager, Storage Operations Edmunds, Inc. 1620 26th Street, Suite 400 South Santa Monica, CA 90404
310-309-4999 desk 310-430-0536 cell
-----Original Message----- From: Parisi, Justin [mailto:Justin.Parisi@netapp.com] Sent: Fri 7/11/2008 5:40 AM To: Leeds, Daniel; toasters@mathworks.com Subject: RE: SUMMARY: Exchange iscsi luns and Snapmanager/SMBR without snapdrive
Honestly Daniel, you should have been able to create the luns any way you wanted when using SnapDrive 6. SnapDrive 6 utilizes not only the RPC, but also allows you to access luns via HTTP and HTTPS, so regardless of how the luns were created, as long as they were NetApp luns, SnapDrive 6 should be able to see them. We have seen some instances of MS hotfixes not being installed and that causing the luns not to show up, however.
________________________________
From: Leeds, Daniel [mailto:dleeds@edmunds.com] Sent: Friday, July 11, 2008 3:53 AM To: toasters@mathworks.com Subject: SUMMARY: Exchange iscsi luns and Snapmanager/SMBR without snapdrive
first off, thanks for all the responses. as usual toasters is quick and reliable.
the issue we had was snapdrive 6 was unable to manage or utilize our iscsi luns that were setup manually from the ontap command line.
this turned into an all day affair with several support calls made by one of our storage admins and the actual exchange admins not being able to do anything on this new cluster setup. this may sound absurd to many since alot of netapp shops are heavily windows based and the filers/storage is managed by the same windows admins. so why would anyone create luns on the command line instead of using snapdrive which simplifies lun management?
a brief background and why a minor detail caused all of this aggrivation. hopefully this will help someone else who might experience this scenario or something similar.
1) we are virtually an all UNIX environment with nearly all storage accessed via NFS and a couple iscsi luns with all filer administration and configuration done via ssh on the ontap command line. filerview is disabled and all the unix iscsi luns are provisioned via the command line and manually mounted on the unix host, partitioned, and filesystems created via the standard unix utilities for each unix variant.
2) a previous exchange cluster did not utilize snapshots and was backed up via the corporate standard in place at that time and thus not only were the luns created manually but they had no space reservation or snapshot reserve and thus no requirement for snapdrive.
3) as we now intend to utilize snapshots with Exchange we had netapp provide a list of recommended versions of the snapshot software based on the windows version and also sat down with a few netapp SE's to validate everything and demo the snapdrive interface and setup. this is where the fun begins as one team with a unix background and only command line administration interact with the Exchange and windows snap products SE and customer implementation engineers--speaking the same language but with different dialects. in a nutshell we asked if snapdrive could manage and "import" existing luns created via the command line. the answer was yes but with one important exception that normally is part of the standard manual provisioning. the luns cannot be mapped and no existing igroups can be utilized by snapdrive. to further compound the confusion the support engineers did correctly advise our admins to unmap the existing luns but without explaining the reason why and only after a couple other troubleshooting steps were suggested that did not work. so our admin was able to eventually get the luns visible in snapdrive but felt like it was more trial and error and did not associate the mapping as the root cause since he was also instructed to delete and recreate luns which worked.
4) the netapp recommended procedure is to utilize snapdrive to create and manage your luns and the correct supportable solution. not being familiar with the product or interface and due to scheduling we did not have an onsite resource to assist us with using snapdrive. we wanted to utilize our usual lun provisioning standards and skills while still utilizing snapdrive to manage mounts and snapshot integration later on in the interest of getting the exchange admins the storage as quick as possible. it was the right approach for us and is fully supported but not the recommended procedure and thus not easy for normal support channels to pick up on the one subtle step that renders manual luns from working with snapdrive.
wow, alot longer than intended but a good experience to share in my opinion. and no we have nothing against snapdrive or windows administration tools :)