How are you using SnapDrive + iSCSI HBAs on a separated storage LAN ?

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