SPTI disks and mounted volumes

[AccuDave]

The configuration first:
Windows 2003 x64 Exterprise on both servers
Starwind 3.1.4 build 20060716
MS Initiator (x64) v2.02 build 1895
HP BL25p servers
HP EVA 6000 FC array
MPIO

The disk I'm trying to offer is a little unique in that it has 20 other volumes mounted within it. (We do this because the files on those mounted volumes are large and change frequently and it's easiest to update them that way).

On the target server, I add the "root-level" disk as an SPTI device in shared R/W mode. On the initiator server, I can log on to the target successfully, and access the top level directory, for both reading and writing, with no problems. when I try to navigate into any of the folders containing a mounted drive, I get the error:

(directoryname) refers to a location that is unavailable. It could be on a hard drive on this computer, or on a network. Check to make sure that the disk is properly inserted, or that you are connected to the Internet or your network, and then try again. If it still cannot be located, the information might have been moved to a different location.

I'm an administrator on both servers. Both servers are in the same domain. The servers aren't in the same subnet, but they do have LAN-speed access to one another.

I can access the mounted volumes through a network share of the "root" drive. I get this same error if I run the Starwind service as LocalService or as a specific account with domain administrative privileges. There is no message in any of the Event Logs for either server. There is nothing in the Starwind log, either.

Can an SPTI device contain mounted volumes? If so, how do I modify my configuration to make them accessible?

[anton (staff)]

Looks like you're using directories which are really symbolic links. Is it correct?

The configuration first:
Windows 2003 x64 Exterprise on both servers
Starwind 3.1.4 build 20060716
MS Initiator (x64) v2.02 build 1895
HP BL25p servers
HP EVA 6000 FC array
MPIO

The disk I'm trying to offer is a little unique in that it has 20 other volumes mounted within it. (We do this because the files on those mounted volumes are large and change frequently and it's easiest to update them that way).

On the target server, I add the "root-level" disk as an SPTI device in shared R/W mode. On the initiator server, I can log on to the target successfully, and access the top level directory, for both reading and writing, with no problems. when I try to navigate into any of the folders containing a mounted drive, I get the error:

(directoryname) refers to a location that is unavailable. It could be on a hard drive on this computer, or on a network. Check to make sure that the disk is properly inserted, or that you are connected to the Internet or your network, and then try again. If it still cannot be located, the information might have been moved to a different location.

I'm an administrator on both servers. Both servers are in the same domain. The servers aren't in the same subnet, but they do have LAN-speed access to one another.

I can access the mounted volumes through a network share of the "root" drive. I get this same error if I run the Starwind service as LocalService or as a specific account with domain administrative privileges. There is no message in any of the Event Logs for either server. There is nothing in the Starwind log, either.

Can an SPTI device contain mounted volumes? If so, how do I modify my configuration to make them accessible?

[AccuDave]

Looks like you're using directories which are really symbolic links. Is it correct?

Yes. I tried to stick with the Windows-specific terminology.

Prior to deploying Starwind in the test setup I've outlined, I had this working on a VMware-based virtual server test platform. I was able to access, both reading and writing, the linked volume on the iSCSI target without error. Those VMs were not only in the same domain but the same subnet as well. I don't know if that makes any difference.[/quote]

[anton (staff)]

Actually it does. We're SAN and not NAS, so user access and symbolic links would not work when storage is moved from one location to other. You need to rework your directory structures to have this SAN volume "system-independent". Have no idea how you've managed to have shares/symbolic links working with VMware on the other system...

Looks like you're using directories which are really symbolic links. Is it correct?

Yes. I tried to stick with the Windows-specific terminology.

Prior to deploying Starwind in the test setup I've outlined, I had this working on a VMware-based virtual server test platform. I was able to access, both reading and writing, the linked volume on the iSCSI target without error. Those VMs were not only in the same domain but the same subnet as well. I don't know if that makes any difference.

[/quote]