Here it is! The iSCSI Target team has compiled a great FAQ to kick off the new release. Checkout these entries and if you have additional questions click the little link below to send me a message and we will continue to build on the FAQ. We hope you are enjoying the nirvana of Windows Storage Server appliances and the iSCSI Software Target! I am forgetting why people ever put hard disks into application servers.
A: iSCSI Software Target 3.2 documentation is available through OEMs with the purchase of an appliance running Windows Storage Server 2008 and the iSCSI Software Target 3.2 (an optional add-on). Or, checkout the new TechCenter for Microsoft iSCSI Software Target 3.2 here: http://technet.microsoft.com/en-us/library/dd573326(WS.10).aspx
A: iSCSI Software Target 3.2 is available through OEMs with the purchase of an appliance running Windows Storage Server 2008. Developers and IHVs who are interested in evaluation versions of Windows Storage Server 2008 and Microsoft iSCSI Software Target 3.2 can obtain them from one of the following locations:
· Embedded Licensing Products Evaluation Registration Site
· MSDN and TechNet subscription sites (you can find out more on Jose Barreto’s blog)
A. Step-by-step instructions are provided in the iSCSI Software Target help file, which is available from the Help menu in the iSCSI Software Target snap-in. Begin with the topic titled “Configuring iSCSI Storage for High Availability.” Your OEM may have provided additional documentation specific to your appliance configuration.
A: The default network properties will force the Network Name resource to attempt to register itself with a DNS Server. This may result in slower than expected iSCSI resource group movement between Windows Storage Server 2008 cluster nodes. The recommendation is to remove the DNS registration requirements by adjusting the appropriate network properties.
1. Open the Network Sharing Center on one of the Windows Storage Server 2008 systems.
2. Select Manage network connections.
3. Select Properties for the iSCSI Network.
4. Select Properties for Internet Protocol Version 4 (TCP/IPv4).
5. Select the Advanced tab.
6. Select the DNS tab.
7. Deselect the Register this connection’s addresses in DNS.
8. Close the Properties for the iSCSI Network.
9. If there are any additional iSCSI networks, repeat Step 3 to 8 for each one.
A: This is the default behavior of the High Availability wizard. We recommend that you use Failover Cluster Manager to delete the resources for DHCP IP addresses that are not required to support iSCSI target access.
A: No, do not use Failover Cluster Manager for this purpose. Editing or deleting these resources can lead to unpredictable results. All management of the iSCSI target and VHDs should be done using the iSCSI Software Target snap-in.
A: iSCSI Software Target automatically deletes these resources. You should never create them directly using Failover Cluster Manager. Instead, use the iSCSI Software Target snap-in.
A: The newly created resource group may be owned by a different node than the one on which you are running the snap-in. You can check the current owner in Failover Cluster Manager (under Services and Applications, click the resource group and look for Current Owner).
If the current owner is not the node on which you are running the iSCSI Software Target snap-in, you will need to do one of the following tasks:
· Move the resource group to the current node using the Failover Cluster Manager snap-in. Just right-click the resource group and then click Move this service or application to another node and select the desired node.
· Switch to the node that’s the current owner and launch the iSCSI Software Target snap-in to create the iSCSI target.
· Use MMC to open a new copy of the iSCSI Software Target snap-in and remotely manage the other node.
A: No, iSCSI Target resource groups cannot function if their disks are in maintenance mode. If you need to perform maintenance on the cluster disks, you must first take the iSCSI Target resource groups offline.
A: We tested the following initiators:
· Microsoft iSCSI Initiator 2.07 and 2.08 in Windows Server 2003
· Microsoft iSCSI Initiator in Windows Server 2008 SP1
· Microsoft iSCSI Initiator in Windows Server 2008 R2 (beta version)
· Qlogic QLE4062C-SP, firmware 3.00.01.24
· RedHat Enterprise Linux v5
· SuSE Enterprise Linux v10
A: Due to Volume Shadow Copy Service requirements, the minimum volume size is 300 MB. If you try to create a virtual disk on a volume smaller than 300 MB, you may see the following error:
The virtual disk cannot be created on the selected volume. The replication operation failed because a required parent object is missing.
The workaround is to extend the size of your volume (if possible) and then try creating the virtual disk again.
A: No, only NTFS volumes are supported. If you use a FAT volume, you’ll get the following error:
A: No, the iSCSI Software Target does not provide a way to shrink iSCSI virtual disks. If you use an initiator to shrink a volume on an iSCSI virtual disk, the virtual disk itself does not shrink accordingly.
A: No, but you can use MPIO for path redundancy.
A: Yes, iSCSI target handles SCSI-3 Persistent Reservation commands.
A. There are three common causes:
· The initiator IQN identifier in the target has a typographical error. Check Target -> Properties -> Initiators. The foolproof method is to copy and paste the initiator IQN into the target’s identifier list.
· The initiator DNS name in the target is not being resolved correctly. This can fail in certain networking environments. See the next question in the FAQ for details.
· The target DNS name entered into the initiator resolves to the wrong IP. Verify that yourtarget.yourdomain.com resolves to the target’s IP address.
If you tried these steps and still can’t connect, check the following:
· Ensure that firewall ports and exceptions are correctly set. Your OEM may have done this at the factory, but if not, you can use the following netsh commands to open the necessary ports on the Windows Storage Server 2008 appliance hosting the iSCSI targets:
netsh advfirewall firewall add rule name="Microsoft iSCSI Software Target Service-TCP-3260" dir=in action=allow protocol=TCP localport=3260
netsh advfirewall firewall add rule name="Microsoft iSCSI Software Target Service-TCP-135" dir=in action=allow protocol=TCP localport=135
netsh advfirewall firewall add rule name="Microsoft iSCSI Software Target Service-UDP-138" dir=in action=allow protocol=UDP localport=138
netsh advfirewall firewall add rule name="Microsoft iSCSI Software Target Service" dir=in action=allow program="%SystemRoot%\System32\WinTarget.exe" enable=yes
netsh advfirewall firewall add rule name="Microsoft iSCSI Software Target Service Status Proxy" dir=in action=allow program="%SystemRoot%\System32\WTStatusProxy.exe" enable=yes
· By default, iSCSI Target does not listen to the auto-configured addresses 169.254.x.x. If you are using an auto-configured address, you’ll have to manually enable these by right clicking on the root node (“Microsoft iSCSI Software Target”) in the iSCSI Software Target snap-in and selecting Properties.
· One quick way to test remote connectivity from an initiator is to telnet to the Windows box using port 3260. If you can’t connect using telnet, then there’s something misconfigured external to the target (e.g., firewall, initiator config, etc).
When configuring initiator access to a target, IQNs are the preferred method and will work regardless of DNS configuration. IQNs are the standard naming convention for identifying targets and initiators, and we encourage customers to use IQNs whenever possible.
For convenience, the option of specifying an initiator’s DNS domain name is built into the iSCSI Software Target snap-in. If you prefer to use DNS names, you can do so as long as DNS is configured correctly (including forward and reverse lookup zones) and you specify the fully qualified domain name (FQDN) of the initiator. If you have difficulty in connecting the target to the initiator after specifying the initiator FQDN, you should check that reverse lookup is enabled correctly by running the following command on the target server:
If the nslookup command fails, then DNS reverse lookup is not configured and you should reconfigure the target to use the initiator IQN.
Alternatively, you can specify a NetBIOS name of the initiator only if the following two conditions are met:
· No DNS reverse lookup zones are configured for the subnet used by the target, and
· Network Discovery or File Sharing is enabled on both the initiator and target servers
A. If you have both IPv4 and IPv6 enabled, and your Windows Storage Server 2008 appliance is restarted, the initiator may hit a bug that causes the initiator to enter a looping Reconnecting state. Hotfix 970658 was released to address this issue.
A. Use Disk Management on the initiator to rescan the disks.
A. The iSCSI Target creates crash-consistent snapshots of virtual disks. For a virtual disk to be restored in a way that is application consistent, so that the server application recovers completely, the snapshots should be made from the iSCSI initiator. This functionality requires the use of the VSS Hardware Provider on the iSCSI initiator server.
A. No, these providers are only needed in the following scenarios:
· You install the Microsoft iSCSI Software Target VDS Hardware Provider on each iSCSI initiator computer running a VDS-aware storage management application (such as Storage Manager for SANs).
· You install the Microsoft iSCSI Software Target VSS Hardware Provider when you want to create transportable snapshots of iSCSI virtual disks and create application-consistent snapshots. You install this hardware provider on the iSCSI initiator server and the server that is to perform backups. The backup software you use must support transporting snapshots.
A. The VSS and VDS providers are provided as part of the iSCSI Software Target package that you received from the OEM. Typically the providers are either installed on the storage appliance or available as a download from the OEM.
A. For the VDS hardware provider, you must run the following netsh command on the initiator:
netsh advfirewall firewall add rule name="Microsoft iSCSI Software Target VDS Hardware Provider" dir=in action=allow program="%SystemRoot%\System32\Wtvdsprov.exe" enable=yes
Best Wishes, iSCSI Target Team