Microsoft iSCSI Software Target 3.2: Known Issues and Updates
Updated: April 14, 2010
Applies To: Microsoft iSCSI Software Target
These release notes provide late-breaking information for Microsoft iSCSI Software Target 3.2, an optional package that can be installed on Windows Storage Server 2008 R2. You can also find more information on the Windows Storage Server blog.
This document contains information about the following releases:
Microsoft iSCSI Software Target 3.2 Update 3
Microsoft iSCSI Software Target 3.2 Update 2
Microsoft iSCSI Software Target 3.2 Update 1
Microsoft iSCSI Software Target 3.2
Microsoft iSCSI Software Target 3.2 Update 3
This update increases the maximum number of concurrent sessions for a single iSCSI target to 140 sessions. However, if using MPIO or failover clustering, the supported limit is still 64 sessions.
KB2439179- Microsoft iSCSI Software Target Update 3
Software requirements:
iSCSI Software Target version 3.2
Windows Storage Server 2008
This update contains two packages:
Iscsitarget32_patch.msp: Use this to update existing systems without resetting the configuration.
Iscsitarget32.msi: This is a full build of Microsoft iSCSI Software Target 3.2. Use this in factory images and first-time installations. This update contains all previous updates and can be considered a roll-up.
Microsoft iSCSI Software Target 3.2 Update 2
Windows Storage Server 2008 Update 4 contains the second update for iSCSI Software Target 3.2.
KB980597 - iSCSI Software Target 3.2 Update
Software requirements:
iSCSI Software Target version 3.2
Windows Storage Server 2008 (x64) Service Pack 2
-OR-
- Windows Storage Server 2008 (x64) Service Pack 1 with KB954475 and KB955656 updates installed.
This update contains two packages:
iscsitarget_patch.msp: This is a partial upgrade that can be used for existing iSCSI installations without needing to reset current configurations.
iscsitarget.msi: This is a full upgrade of iSCSI Software Target 3.2 that can be used in factory images and for first-time installations
Microsoft iSCSI Software Target 3.2 Update 1
This update fixes problems in the following areas:
Rolling back large disks (GPTs).
Using the Offline function of the target while initiators are logging on.
Creating Volume Shadow Copy Service (VSS) snapshots.
Microsoft iSCSI Software Target 3.2
Microsoft iSCSI Software Target 3.2 contains the following known issues:
OEM Preinstallation
These notes apply to Original Equipment Manufacturers (OEMs) of the Microsoft iSCSI Software Target.
VendorSpecificIDLow and VendorSpecificIDHigh registry entries must both be 0 to generate random values.
If you set both the VendorSpecificIDLow and the VendorSpecificIDHigh registry entries to 0 (0x00000000), Microsoft iSCSI Software Target will generate a random value for both values to uniquely identify the target.
Vendor-specific registry entries do not support Unicode values.
The vendor-specific registry entries for Microsoft iSCSI Software Target (VendorID, ProductID, and ProductRevision) do not support Unicode values. If you assign a value to any of these registry values, an iSCSI initiator will display “????” for the values.
General
These notes apply to end users of the Microsoft iSCSI Software Target.
Do not rename resources outside of the Microsoft iSCSI Software Target console .
If you rename an iSCSI resource after it is created, unexpected results may occur. If a resource is renamed with another tool, such as Failover Cluster Management, different naming rules may apply that may lead to issues for Microsoft iSCSI Software Target. For example, Failover Cluster Management permits a resource name to contain a space, whereas Microsoft iSCSI Software Target does not.
If an iSCSI resource has been renamed, delete the resource, stop the Microsoft iSCSI Software Target service, and then restart the service and recreate the resource.
Increase iSCSI initiator timeout value when you use Failover Clustering.
If you enable IPSec on connections from iSCSI initiators to a failover cluster running Microsoft iSCSI Software Target, you should increase the iSCSI initiator timeout value. Increasing the timeout value will prevent communication failures when a failover node goes offline and the operation in progress is transferred to another node of the failover cluster. To work around this issue, increase the following registry value to 90:
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\<Instance Number>\Parameters
The values that can be modified are:
MaxRequestHoldTime – Increase this value to 90 if MPIO is not installed.
LinkDownTime – Increase this value to 90 if MPIO is installed.
Removing a shared disk from a resource group may not automatically force virtual disks offline.
If you remove a disk from a resource group in the Failover Cluster Management console and move the disk to another resource group, any virtual disks hosted on that disk may not be automatically forced offline during the move. To work around this issue, you can either delete the virtual disks before moving the disk to a new resource group, or use Failover Cluster Management to move the virtual disks to the same destination resource group as the hosting disk.
Uninstalling Microsoft iSCSI Software Target from a failover cluster may take a long time.
When you attempt to uninstall Microsoft iSCSI Software Target from the last node of a failover cluster that is currently hosting virtual disk resources in a pending or failed state, the uninstall may take an unusually long time to complete. To avoid this delay, delete the resource groups from the Microsoft iSCSI Software Target console prior to uninstalling the software on the last node of the failover cluster. If the resource groups are not deleted, you must wait for the uninstall process to complete.
After renaming a failover cluster, you must restart the Microsoft iSCSI Software Target service.
If you rename a failover cluster after installing Microsoft iSCSI Software Target, you must stop and restart the Microsoft iSCSI Software Target service before the new cluster name will be displayed by the Microsoft iSCSI Software Target console.
Must reinstall Microsoft iSCSI Software Target on all failover cluster nodes if one node is uninstalled.
If you uninstall Microsoft iSCSI Software Target from one node of the failover cluster, and then choose to reinstall, you must uninstall, restart the storage appliance, and then reinstall Microsoft iSCSI Software Target on every node of the failover cluster to restore functionality. Failure to uninstall, restart, and then reinstall on every node will result in the Microsoft iSCSI Software Target service failing to start.
Microsoft iSCSI Software Target console may not update when you create a failover cluster.
If you have the Microsoft iSCSI Software Target console open when you create a failover cluster, the wizards in the console will not display cluster resources. You must close the Microsoft iSCSI Software Target console and then open it after the cluster has been created to enable the wizards to display the failover cluster resources.
Maximum number of simultaneous local mount virtual disks.
Microsoft iSCSI Software Target supports up to 4 locally mounted virtual disks and snapshots per node in a failover cluster at one time.
Event generated on dismount of virtual disk.
When you dismount a locally mounted virtual disk, the following event may be generated in the System log:
Plugplaymanager 12 event:
The device 'MSFT 00000000F852A09D SCSI Disk Device' (SCSI\Disk&Ven_MSFT&Prod_00000000F852A09D\1&2afd7d61&3&000003) disappeared from the system without first being prepared for removal.
These events may be safely ignored for normal Microsoft iSCSI Software Target dismount operations.
Disabling a virtual disk during a rollback will terminate the rollback without warning.
If you disable a virtual disk while performing a rollback operation, the rollback will be silently ended. An event is logged documenting that the rollback was ended.
Locally mounted virtual disks may appear in available drives list when creating a new virtual disk.
When you create a new virtual disk, locally mounted virtual disks are displayed in the list of available volumes to host the new virtual disk. Using a locally mounted virtual disk to store a virtual disk is unsupported. If you attempt to select the locally mounted virtual disk as the storage location for the new virtual disk, you will receive the following error message:
The wizard was unable to import one or more virtual disks. Make sure that the files are not in use, and then run the wizard again.
iSCSI initiator may be unable to discover a target by using the DNS domain name.
When configuring initiator access to an iSCSI target, IQNs are the preferred method and will work regardless of DNS configuration.
For convenience, the option of specifying a DNS domain name is built into the Microsoft iSCSI Software Target snap-in. If you prefer to use DNS names, you may do so as long as DNS is configured correctly (including forward and reverse lookup zones) and if 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, check that DNS reverse lookup is enabled correctly by running the following command on the target server: nslookup <InitiatorIP> where <InitiatorIP> is the IP address of the iSCSI initiator. If the nslookup command fails, then DNS reverse lookup is not configured and you should reconfigure the target to use the initiator IQN, IP address, or MAC address.
Alternatively, you can use a NetBIOS name to connect the initiator only if the following two conditions are met:
No DNS reverse lookup zones are configured for the subnet used by the target.
Network Discovery or File Sharing is enabled on both the initiator and target servers.
Rollback operations on a locally mounted virtual disk may take a long time to complete.
When you mount a virtual disk locally in read/write mode, any rollback operation performed on that virtual disk will take a long time to complete.
Managing Microsoft iSCSI Software Target while moving a resource group may cause instability.
When you perform operations on a remote Microsoft iSCSI Software Target resource group in Failover Cluster Management, you will see the status of the resource group change to “Pending.” If you attempt to execute another operation while the resource group is pending, you may get unpredictable results.
Additional firewall rules may be required for iSCSI initiators.
In addition to the Windows Firewall exceptions listed in the documentation, you may need to enable additional rules to connect an iSCSI initiator to Microsoft iSCSI Software Target on Windows Storage Server 2008. The required Windows Firewall rules include:
Windows Management Instrumentation (WMI-In) [TCP/All ports]
Windows Management Instrumentation (DCOM-In) [TCP/Port 135]
Windows Management Instrumentation (ASync-In) [TCP/All ports]
Windows Management Instrumentation (WMI-Out) [TCP/All ports]
Remote Volume Management (RPC-EPMAP) [TCP/RPC Endpoint Mapper]
Remote Volume Management - Virtual Disk Service Loader (RPC) [TCP/Dynamic RPC]
Remote Volume Management - Virtual Disk Service (RPC) [TCP/Dynamic RPC]
Do not make shadow copies of local-mounted volumes.
When you locally mount a virtual disk, and then try to make a shadow copy of that volume such as using Windows Explorer, the storage appliance may appear to hang. This is because of the way that shadow copies are created. When you make a shadow copy of a locally mounted virtual disk, the local mount driver will write to the underlying volume that hosts the virtual disk, which then causes an additional write to the differencing area on the host volume. The result is a circular series of writes that eventually cause the storage appliance to stop responding. If you encounter this scenario, restart the storage appliance.
After destroying a failover cluster, Microsoft iSCSI Software Target service must be reinstalled.
If you have Microsoft iSCSI Software Target installed on a failover cluster, and then destroy that failover cluster, you must uninstall, restart the storage appliance, and then reinstall Microsoft iSCSI Software Target before creating a new failover cluster. This forces Microsoft iSCSI Software Target to remove its configuration for the previous failover cluster, and prepares it to recognize the new failover cluster configuration. This also applies to a storage appliance that is removed from a failover cluster before it can be added to a different failover cluster.
Microsoft iSCSI Software Target console may display an incorrect location for snapshot storage.
In cases where you have not explicitly set the location of snapshot storage for a volume, the Microsoft iSCSI Software Target console may display the incorrect location. When the location is not explicitly defined, or if the setting has been deleted, the Volume Shadow Copy Service will implicitly set the location to an available volume that might not be appropriate for your configuration, such as a volume that is not part of the same storage group. To avoid this issue, you should explicitly define the location of the snapshot storage for the volume. This can be done with the Microsoft iSCSI Software Target console, through Volume Properties in Windows Explorer, or from the command line using Vssadmin.exe.
Use Microsoft iSCSI Software Target console to remove snapshots.
You should always use the Microsoft iSCSI Software Target console to remove snapshots. Using utilities such as Vssadmin.exe or Vshadow.exe to delete a snapshot created with Microsoft iSCSI Software Target may cause unpredictable results.
Bad IP addresses may cause the initiator to fail to restore a lost connection.
In some cases where the iSCSI initiator loses communication with Microsoft iSCSI Software Target, the initiator may appear to hang while reconnecting. This issue can occur if there are IP addresses on the server that runs Microsoft iSCSI Software Target that are not being used to communicate with the initiator. The initiator will attempt to connect on each configured IP address and will wait up to 100 seconds for a response.
This issue can also be caused by automatic private IP address assignments (169.x.x.x). To prevent this, use static IP addresses where DHCP is unavailable.
You can work around this issue using the following options:
Specify the source and target portal by IP address.
Use only IPv4 addresses or IPv6 addresses: do not mix the types of address.
Disable network cards that are not connected to a network.
Cluster drive configuration.
To avoid possible issues with iSCSI targets during node failover, the Windows Storage Server 2008 operating system should be installed on the same drive configuration on each node, typically the C: drive.
Snapshot status value may be delayed.
When you locally mount a snapshot, the snapshot status value in the instance of the WMI class WT_Snapshot and property Status does not immediately receive the status bit flag DVMounted when the method call DVMount returns. The status should resolve after a short wait.
Stop the Microsoft iSCSI Software Target service before uninstalling.
You may encounter errors in Event Viewer when attempting to uninstall Microsoft iSCSI Software Target 3.2 and subsequently reinstalling. As a workaround, stop the Microsoft iSCSI Software Target service prior to uninstalling the software. If the software has already been uninstalled, you should restart the computer prior to reinstalling Microsoft iSCSI Software Target.
Snapshot storage is limited to 8 exabytes.
Shadow storage used for snapshots is limited to 8 exabytes. The Microsoft iSCSI Software Target console will permit you to enter a value greater than 8 exabytes, and then the value will be reset to 8 exabyte after you save the value.