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
Filip,
Please contact me directly and I'll help you get this going.
Thanks!
-Charles
-----Original Message----- From: Filip Sneppe [mailto:filip.sneppe@gmail.com] Sent: Wednesday, May 27, 2009 8:01 PM To: NetApp list Subject: 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
Hi all,
Thanks for the replies I've received about this. I think the main error I've made on this is to also install the MS iSCSI initiator in addition to the iSCSI service.
I've fixed one setup (2 servers, and there was also an iSCSI name difference between the MS iSCSI initiator name and the iSCSI name on the HBA due to a typo), and I've made an appointment for tomorrow to go look at the other implementation.
I'll report back to this list when I have some more info to add to this.
Best regards, Filip
On Thu, May 28, 2009 at 2:01 AM, Filip Sneppe filip.sneppe@gmail.com wrote:
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
Hi all,
Just to make sure this goes to the archives and others can benefit from this mail thread:
The reason why things didn't work on my setups, was because I had installed both the MS iSCSI initiator and iSCSI service, when only the iSCSI service should have been installed.
Again, thanks to all who helped me see the light on this one.
Best regards, Filip
On Thu, May 28, 2009 at 5:02 PM, Filip Sneppe filip.sneppe@gmail.com wrote:
Hi all,
Thanks for the replies I've received about this. I think the main error I've made on this is to also install the MS iSCSI initiator in addition to the iSCSI service.
I've fixed one setup (2 servers, and there was also an iSCSI name difference between the MS iSCSI initiator name and the iSCSI name on the HBA due to a typo), and I've made an appointment for tomorrow to go look at the other implementation.
I'll report back to this list when I have some more info to add to this.
Best regards, Filip
On Thu, May 28, 2009 at 2:01 AM, Filip Sneppe filip.sneppe@gmail.com wrote:
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
-
Filip Sneppe -
Ledbetter, Charles