Thanks for the replies I've received about this. I think the main
this is to also install the MS iSCSI initiator in addition to the iSCSI service.
> Hi,
>
> I am struggling to get the following setup to work properly:
>
> - A separated storage IP subnet, not routed to the LAN
> - A multihomed NetApp filer with an IP address on both the storage IP
> subnet and the LAN
> - A Windows 2003 server with a normal NIC on the LAN and an iSCSI HBA
> on the storage subnet.
> - The iSCSI HBA is a dual Qlogic HBA, but only one of them is connected,
> the other one is left unconfigured. I don't intend to use MPIO.
> - The setups I've worked on lately have all been boot-from-SAN setups,
> but I don't know if that's really relevant to the problem.
>
> Now, presenting LUNs and using them on the server (or even booting
> from them) has not
> been much of a problem, no issues there.
>
> The problem arises when I want to use SnapDrive for LUN management tasks
> such as snapshotting. From the docs I've read, what I gather is that I have to
> install the MS iSCSI initiator even when using iSCSI HBAs:
>
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb8988> (this doc is not 100% clear to me: should I only select the iSCSI
> service during
> the installation, or also the MS iSCSI initiator itself ? What is the impact
> of selecting the MS iSCSI MPIO ?)
>
> I also make sure to change the initiator name on the HBA to the iSCSI
> initiator name used by the MS iSCSI initiator:
>
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb21672>
> The end result is that my LUNs are accessible from the HBA. However, when
> opening the Computer Management MMC and going to the disks managed by
> SnapDrive, no disks are shown and the SnapDrive service is logging that
> filer IP address a.b.c.d is dead, as described in this article:
>
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb30762>
> This article talks about fixing up domain credentials and name resolution,
> but from a network routing point of view, I can see where this error is
> coming from: the Windows server is not aware of the HBA connected to the
> storage segment and cannot reach it via its normal NIC, so it
> reports a dead filer IP address.
>
> Now, the quick fix would be to add the necessary routes to/from the storage IP
> network, but that would mean that this network is no longer fully isolated
> from the rest of the network, whcih I would very much like to avoid.
>
> What really drives me mad is that I have a setup at a customer site
> described as above that works perfectly fine (ie. SnapDrive shows the
> LUNs in the MMC and SMSQL can create snapshots & backups), yet
> I have another customer site where SnapDrive is unable to do anything
> because it cannot find the LUNs.
>
> Just today I was at a customer site with a setup as described above,
> where SnapDrive was able to work with the LUNs. They hadn't installed
> the host utilities, so I did the following:
> - Installed a MS hotfix required by the host utils
> - Installed the host utils
> - uninstalled a version of SMSQL and installed version 2.1.2
> After a server reboot: boom, SnapDrive doesn't see ane LUNs any more,
> so no way to take any snapshots any more of these LUNs.
>
> So that's two out of three setups that are not working.
>
> I fiddled around a little with things: ie. installed the MS iSCSI MPIO,
> reinstallled the host utils (5.1) with MPIO support, etc.
> At one point, I had uninstalled the host utils & SMSQL, and then
> reinstalled the MS iSCSI initiator and SnapDrive, and I saw the
> LUNs again using MMC. I reboot one last time to make sure
> everything's fine, and ... bang ... no more visible LUNs from SnapDrive.
>
> So at this point I would like to know:
> - Has anyone had similar experiences ?
> - If you are using iSCSI HBAs on a separated storage network, what is
> your magic formula to get things working correctly ?
> Should I be able to get this thing to work without adding a route to
> the storage network ?
>
> Thanks in advance for your suggestions !
>
> Best regards,
> Filip
>