Microsoft Windows Configuration Guide (Formerly Known as FAQ 1560)
This topic includes:
Known Issues in Microsoft Windows Configuration Guide
Overview
This guide provides configuration settings and considerations for Hosts running Microsoft Windows with SANsymphony.
Basic Windows storage administration skills are assumed including how to connect to iSCSI and Fibre Channel target ports and the discovering, mounting and formatting of disk devices.
Change Summary
Refer to the DataCore FAQ 838 for the latest version of the FAQ.
Changes since February 2024
| Section(s) | Content Changes | ||||
|---|---|---|---|---|---|
| DataCore Windows Integration Kit (WIK) |
|
||||
| VSS - DataCore Windows Integration Kit (WIK) |
|
||||
| SCSI UNMAP |
|
Compatibility Lists
MPIO
For versions 1.x and 2.x this was formerly known as DataCore’s Host Integration Kit (HIK).
Applies to SANsymphony 10.x installations only.
Hosts still connected to SANsymphony 9.x or earlier please contact DataCore Technical Support for advice.
DataCore Windows Integration Kit (WIK)
|
Version |
With ALUA |
Without ALUA |
|---|---|---|
|
Windows 10 and earlier |
Not Supported |
Not Supported |
|
2000 / 2003 |
||
|
2008 |
Not Supported |
Qualified 1 |
|
2008 R2 |
Qualified |
Not Supported |
|
2012 |
Qualified 2 |
Qualified 3 |
|
2012 R2 |
Qualified 4 |
Not Supported |
|
2016 |
Qualified 5 |
Not Supported |
|
2019 |
Qualified 6 |
Not Supported |
|
2022 |
Qualified 7 |
Not Supported |
Qualified vs. Not Qualified vs. Not Supported
Refer to Qualified vs. Not Qualified vs. Not Supported for definitions.
DataCore Server Front-End Port connections
Both Fibre Channel and iSCSI connections are supported on all versions of Windows that are considered ‘Qualified’.
Host requirements when using DataCore Windows Integration Kit with SANsymphony
Please refer to the DataCore Windows Integration Kit's user guide.
VSS
Applies to all versions of SANsymphony 10.x.
DataCore Windows Integration Kit (WIK)
|
Version |
|
|---|---|
|
Windows 10 and earlier |
Not Supported |
|
2000 / 2003 / 2008 / 2008 R2 |
Not Supported |
|
2012 / 2012 R2 |
Qualified |
|
2016 8 |
Qualified |
|
2019 |
Qualified 9 |
|
2022 |
Qualified 10 |
Microsoft's Own VSS Hardware Provider
|
Version |
|
|---|---|
|
All Windows versions |
Does not work (see notes below) |
Microsoft’s VSS Shadow Copy commands can be run on the Host to any served Virtual Disk as regular storage devices, but there is no integration with SANsymphony’s Snapshot or Continuous Data Protection (CDP) functions. For that please install the DataCore’s own VSS component from the 'DataCore Windows Integration Kit' software package.
Refer to DataCore Windows Integration Kit for more information.
Offloaded Data Transfers (ODX)
Applies to all versions of SANsymphony 10.x.
|
Version |
|
|---|---|
|
2000 / 2003 |
Does not work |
|
2008 / 2008 R2 |
Tested/Works |
|
2012 / 2012 R2 |
Tested/Works |
|
2016 |
Tested/Works |
|
2019 |
Tested/Works |
|
2022 |
Tested/Works |
ODX will not work with files smaller than 256Kb, see the 'Known Issues' section later on in this document. For End-of-Life versions of SANsymphony, ODX is not supported regardless of the Windows operating system and must be disabled on the Host.
SCSI UNMAP
Applies to all versions of SANsymphony 10.x.
|
Version |
|
|---|---|
|
2000 / 2003 |
Does not work UNMAP was not implemented in Windows 2000 / 2003 |
|
2008 / 2008 R2 |
Does not work UNMAP commands are ignored for Windows 2008 / 2008 R2 Hosts |
|
2012 / 2012 R2 |
Supported |
|
2016 |
Supported |
|
2019 |
Supported |
|
2022 |
Supported |
Qualified vs. Not Qualified vs. Not Supported
Qualified
This combination has been tested by DataCore and all the host-specific settings listed in this document applied using non-mirrored, mirrored and Dual Virtual Disks.
Not Qualified
This combination has not yet been tested by DataCore using Mirrored or Dual Virtual Disks types. DataCore cannot guarantee 'high availability' (failover/failback, continued access etc.) even if the host-specific settings listed in this document are applied. Self-qualification may be possible please see Technical Support FAQ #1506.
Mirrored or Dual Virtual Disks types are configured at the users own risk; however, any problems that are encountered while using Windows versions that are 'Not Qualified' will still get root-cause analysis.
Non-mirrored Virtual Disks are always considered 'Qualified' - even for 'Not Qualified' combinations of Windows/SANsymphony.
Not Supported
This combination has either failed 'high availability' testing by DataCore using Mirrored or Dual Virtual Disks types; or the operating System's own requirements/limitations (e.g. age, specific hardware requirements) make it impractical to test. DataCore will not guarantee 'high availability' (failover/failback, continued access etc.) if the host-specific settings listed in this document are applied. Mirrored or Dual Virtual Disks types are configured at the users own risk. Self-qualification is not possible.
Mirrored or Dual Virtual Disks types are configured at the users own risk; however, any problems that are encountered while using Windows versions that are 'Not Supported' will get best-effort Technical Support (e.g. to get access to Virtual Disks) but no root-cause analysis will be done.
Non-mirrored Virtual Disks are always considered 'Qualified' – even for 'Not Supported' combinations of Windows/SANsymphony.
Windows Versions that are End of Life
For versions that are listed as 'Not Supported', self-qualification is not possible. For versions that are listed as 'Not Qualified', self-qualification may be possible if there is an agreed ‘support contract’ with Microsoft as well. Please contact DataCore Technical Support before attempting any self-qualification.
For any problems that are encountered while using Windows versions that are EOL with DataCore Software, only best-effort Technical Support will be performed (e.g. to get access to Virtual Disks). Root-cause analysis will not be done.
Non-mirrored Virtual Disks are always considered 'Qualified'.
The DataCore Server Settings
Operating System Type
When registering the Host choose one of the appropriate options:
- Windows 2022 / 2019 / 2016 choose 'Microsoft Windows 2012 and later’
Only available with SANsymphony 10.0 PSP 6 or later for SANsymphony 10.0 PSP5 and earlier use ‘Microsoft Windows 2012’. - All earlier Windows versions choose ‘Microsoft Windows’
Port Roles
Ports that are used to serve Virtual Disks to Hosts should only have the Front End role checked. While it is technically possible to check additional roles on a Front End port (i.e. Mirror and Backend), this may cause unexpected results after stopping the SANsymphony software.
Any port with front-end role (and is serving Virtual Disks to Hosts) also has either the mirror and/or backend role enabled will remain ‘active’ even when the SANsymphony software is stopped. There is some slight difference in behavior depending on the version of SANsymphony installed.
- SANsymphony 10.0 PSP 7 and Earlier
Any port that has the mirror and/or back-end role checked will remain ‘active’ after the SANsymphony software has been stopped.
- SANsymphony 10.0 PSP 8 and Later
Only ports with the back-end role checked will remain ‘active’ after the SANsymphony software has been stopped.
Front-end ports that are serving Virtual Disks but remain active after the SANsymphony software has been stopped can cause unexpected results for some Host operating systems as they continue to try to access Virtual Disks from the ‘active’ port on the now-stopped DataCore Server. This, in turn, may end up delaying Host fail-over or result in complete loss of access from the Host’s application/Virtual Machines.
Multipathing
The Multipathing Support option should be enabled so that Mirrored Virtual Disks or Dual Virtual Disks can be served to Hosts from all available DataCore FE ports. Refer to the Multipathing Support section for more information.
Non-mirrored Virtual Disks and Multipathing
Non-mirrored Virtual Disks can still be served to multiple Hosts and/or multiple Host Ports from one or more DataCore Server FE Ports if required; in this case the Host can use its own multipathing software to manage the multiple Host paths to the Single Virtual Disk as if it was a Mirrored or Dual Virtual Disk.
ALUA Support
The ALUA support option (Asymmetrical Logical Unit Access) should be enabled if required and if Multipathing Support has been enabled (see above). Refer to the Compatibility Lists table to see which combinations of Microsoft Windows and SANsymphony support ALUA.
More information on Preferred Servers and Preferred Paths used by the ALUA function can be found in Appendix A.
Serving Virtual Disks
For the first time
DataCore recommends that before serving Virtual Disks for the first time to a Host, that all DataCore Front-End ports on all DataCore Servers are correctly discovered by the Host first. Then, from within the SANsymphony Console, the Virtual Disk is marked Online, up to date and that the storage sources have a host access status of Read/Write.
To more than one Host port
DataCore Virtual Disks always have their own unique Network Address Authority (NAA) identifier that a Host can use to manage the same Virtual Disk being served to multiple Ports on the same Host Server and the same Virtual Disk being served to multiple Hosts.
While DataCore cannot guarantee that a disk device's NAA is used by a Host's operating system to identify a disk device served to it over different paths generally we have found that it is. And while there is sometimes a convention that all paths by the same disk device should always using the same LUN 'number' to guarantees consistency for device identification, this may not be technically true. Always refer to the Host Operating System vendor’s own documentation for advice on this.
DataCore's Software does, however always try to create mappings between the Host's ports and the DataCore Server's Front-end (FE) ports for a Virtual Disk using the same LUN number where it can. The software will first find the next available (lowest) LUN 'number' for the Host-DataCore FE mapping combination being applied and will then try to apply that same LUN number for all other mappings that are being attempted when the Virtual Disk is being served. If any Host-DataCore FE port combination being requested at that moment is already using that same LUN number (e.g. if a Host has other Virtual Disks served to it from previous) then the software will find the next available LUN number and apply that to those specific Host-DataCore FE mappings only.
To Microsoft Cluster nodes
Define one Host for each Windows cluster node in the SANsymphony Management Console – i.e. do not create a single Host entry to represent all the nodes in a cluster.
Cluster nodes that have more than one port connected to one or more DataCore Servers will also require additional fail-over software (i.e. MPIO) to be able to failover between its own connected ports rather than just to another cluster node.
DataCore recommend that you run the ‘Validate Configuration’ wizard each time new Virtual Disks are served before they are used for production data to confirm that they will function correctly.
The Windows Host Settings
Disk Timeout
TimeoutValue
Using regedit browse to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk
All hosts must have a value of 0x0000003c – 60 seconds. Depending on the version of Windows you are using and the MPIO software installer, this may already be set correctly. Refer to MPIO-Specific Parameters for more details.
Changing this value will require a reboot of the server.
Microsoft Cluster Specific Settings
Using a File Share witness
No additional settings are required.
Using a Disk witness
Change the $cluster.QuorumArbitrationTimeMax value to 60 seconds.
Run the following PowerShell commands:
$cluster = Get-Cluster
$cluster.QuorumArbitrationTimeMax=60
Verify that the setting has been enabled:
$cluster.QuorumArbitrationTimeMax
Example:
- This is a global setting that applies to all hosts in the cluster. No reboot is needed and is effective immediately.
- Changing a cluster from a ‘File Share’ to a ‘Disk’ witness will (re)set the value (back) to the default 20 seconds. Re-run the PowerShell commands and verify that the setting is 60.
- The setting may revert to 20 seconds after any reboot of the cluster. Always verify the value after any reboot (and re-run the commands above, if required).
MPIO-Specific Parameters
This applies to Hosts using either Microsoft’s own MPIO – also see Appendix C or the MPIO component from DataCore Windows Integration Kit (WIK).
Run the PowerShell command:
Get-MPIOsetting
The expected values:
For Get-MPIOsetting PowerShell command, DiskTimeoutValue can be set via the registry using the value 0x0000003c (60). For more information, refer to Windows Host Settings.
If any of the values above are not the same as your own system, they can be changed using the Set-MPIOsetting PowerShell command. A reboot may be needed.
Example:
Refer to Set-MPIOSetting for more information.
Known Issues
The following is intended to make DataCore Software users aware of any issues that affect performance, access or may give unexpected results under particular conditions when SANsymphony is used in configurations with Microsoft Windows Hosts.
These Known Issues may have been found during DataCore’s own testing but others may have been reported by our users when a solution was found that was not to do with DataCore’s own products.
DataCore cannot be held responsible for incorrect information regarding another vendor’s products and no assumptions should be made that DataCore has any communication with these other vendors regarding the issues listed here.
We always recommend that the vendor’s should be contacted directly for more information on anything listed in this section.
For ‘Known issues’ that apply to DataCore Software’s own products, please refer to the relevant DataCore Software Component’s release notes or user guides.
Unless explicitly stated:
Windows 2008 includes both the SP2 and 'non-SP2' versions
Windows 2012 includes both the R2 and 'non-R2' versions
MPIO – Microsoft and DataCore WIK
Affects Windows 2008 / 2012 / 2012 R2 / 2016 with updates older than July 2017
Microsoft's multipath bus driver (MPIO.sys) may not failover if two or more paths from a Host to a Virtual Disk fail at the same time, or if the same Virtual Disk for two or more paths is unavailable.
This will affect Hosts using either DataCore's MPIO (e.g. the DataCore Windows Integration Kit) or Microsoft's own 'built-in' MPIO - both of which rely on the MPIO.sys driver of the Windows operating system.
The Microsoft MPIO.sys driver builds its own list of all paths to any given disk device (e.g. a Virtual Disk) which also includes the path that is designated as the 'next' path available for failover if the active path (e.g. the path that is being used at that moment to send IO) reports an error either on the path or to the disk device itself. If an event, such as a disk device or connection failure, cause both the active and the 'next' path (determined by the MPIO.sys driver) to lose access to the same disk device, then no failover will occur even if there are other paths available to that same disk device.
In this case the Host will lose access to the Virtual Disk.
This issue was fixed in the following Windows updates:
For Windows 2019:
N/A – Windows 2019 was not released when this issue was discovered and then fixed. Therefore, all Windows 2019 installations are unaffected by this problem.
For Windows 2016:
Fixed in any Windows Update after June 27, 2017—KB4022723
"Addressed issue where you may lose access to storage disks when there are still available paths if there is an error on one of the multipath I/O paths."
For Windows 2012 R2:
Fixed in any Windows Update after July 11, 2017—KB4025336 (Monthly Rollup)
"Addressed an issue where MPIO failover stops after a disk has been surprise removed, identified by Event ID 157: "Disk X has been surprised removed" when there are still viable paths to use. Scenario may occur when the newly selected path belongs to the disk that has been surprised removed."
For Windows 2008 / 2012 (non-R2):
No fix from Microsoft was ever issued for either of these versions of Windows Server. Therefore, as the problem is in Microsoft's own multipath bus driver, and because it is impossible for DataCore to know which is going to be the 'next' designated active path at any given moment (as this is decided by the MPIO.sys driver) the only safe configuration which will guarantee failover is when a mirrored Virtual Disk is served to only one Host (FE) port from each DataCore Server.
Affects Windows 2008 / 2012 / 2012 R2
Hosts using DataCore Windows Integration Kit or DataCore's MPIO do not use the Preferred DataCore Server immediately after a restart.
The host's operating system scans for the first available hardware path as it starts up and uses it regardless if the path is on the preferred DataCore Server or not. The device path discovery is usually decided by the order of the Host's PCI slots in the Host Server and is beyond the control of the DataCore MPIO software. Once all available device paths have been detected by the host however, the Host will (eventually) move over to the path on the 'preferred' DataCore Server.
Microsoft Cluster Services (MSCS)
Affects Windows 2008 / 2012 / 2012 R2
The Microsoft Cluster Validation test may report a warning message about an unsigned DataCore Multipath driver (even though the driver is signed).
Microsoft has confirmed that in this case this message is benign and can be safely ignored and they will support MSCS with the latest version of DataCore Windows Integration Kit.
Fibre Channel
Affects Windows 2008 / 2012 / 2012 R2 / 2016 / 2019
16 GB QLogic Fibre Channel Host Bus Adaptors
Do not use driver version 9.1.17.21 with firmware older than 08.03.00 when connecting to DataCore Server Front-end ports using SANsymphony-V versions 10.0 PSP 4 Update 1 or earlier as in some cases this firmware on the Host can cause the DataCore Server to crash.
Affects Windows 2008 / 2012 / 2012 R2 / 2016
2 or 4 GB QLogic Fibre Channel Host Bus Adaptors
Do not use driver versions 9.0.1.12 or 9.0.2.11 as they may cause unexpected disconnections from the DataCore Server.
ODX and SCSI UNMAP/TRIM
Affects Windows 2008 / 2012 / 2012 R2 / 2016 / 2019 / 2022
Off Load Data Transfers (ODX) will not be used for files smaller than 256 Kb
File transfers for files smaller than 256 kb will take place using 'traditional' copy methods so large numbers of these small, files may impact Host performance for the duration of the transfer. Refer to Offloaded Data Transfer.
Affects Windows 2012 / 2012 R2 / 2016 / 2019 / 2022
Formatting a Virtual Disk may take longer than expected.
During the formatting of any filesystem, Windows will (by default) issue SCSI UNMAP write I/O for the entire size of the filesystem. This will mean that the filesystem format process may take a long time to complete and will generate significant write I/O to the Disk Pool regardless if the 'Perform a quick format' option is checked or not. The recommendation from DataCore is to disable the 'SCSI TRIM and UNMAP' feature on the Windows Host just for the duration of the format.
Method 1:
-
From a CMD window on the Host, run the fsutil command:
This disables all the UNMAP commands from the Host. -
After the format has completed, re-enable the UNMAP feature by running the command:
The command takes effect immediately and without any impact on the Windows Host. -
To verify the current setting for UNMAP, run the command:
DisableDeleteNotify=0 - indicates the UNMAP feature is enabled.
DisableDeleteNotify=1 - indicates the UNMAP feature is disabled.Disabling UNMAP will not affect the Windows ODX (offline data transfer) feature or vice versa.
Method 2:
- Create a virtual disk of size 1 GB and serve it to the host.
- Format the disk with NTFS on the host. The disk formatting should get completed quickly.
- Resize the virtual disk in SANsymphony to the desired size. Please ensure that the new size is larger than the original size.
- Rescan the host to view the size of the disk expand.
- Extend the NTFS volume to the desired size. The NTFS partition should get extended quickly.
Appendices
A: Preferred Server and Preferred Path Settings
Without ALUA Enabled
If Hosts are registered without ALUA support, the Preferred Server and Preferred Path settings will serve no function. All DataCore Servers and their respective Front End (FE) paths are considered ‘equal’.
It is up to the Host’s own Operating System or Failover Software to determine which DataCore Server is its preferred server.
With ALUA Enabled
Setting the Preferred Server to ‘Auto’ (or an explicit DataCore Server), determines the DataCore Server that is designated ‘Active Optimized’ for Host IO. The other DataCore Server is designated ‘Active Non-Optimized’.
If for any reason the Storage Source on the preferred DataCore Server becomes unavailable, and the Host Access for the Virtual Disk is set to Offline or Disabled, then the other DataCore Server will be designated the ‘Active Optimized’ side. The Host will be notified by both DataCore Servers that there has been an ALUA state change, forcing the Host to re-check the ALUA state of both DataCore Servers and act accordingly.
If the Storage Source on the preferred DataCore Server becomes unavailable but the Host Access for the Virtual Disk remains Read/Write, for example if only the Storage behind the DataCore Server is unavailable but the FE and MR paths are all connected or if the Host physically becomes disconnected from the preferred DataCore Server (e.g. Fibre Channel or iSCSI Cable failure) then the ALUA state will not change for the remaining, ‘Active Non- optimized’ side. However, in this case, the DataCore Server will not prevent access to the Host nor will it change the way READ or WRITE IO is handled compared to the ‘Active Optimized’ side, but the Host will still register this DataCore Server’s Paths as ‘Active Non-Optimized’ which may (or may not) affect how the Host behaves generally.
In the case where the Preferred Server is set to ‘All’, then both DataCore Servers are designated ‘Active Optimized’ for Host IO.
All IO requests from a Host will use all Paths to all DataCore Servers equally, regardless of the distance that the IO has to travel to the DataCore Server. For this reason, the ‘All’ setting is not normally recommended. If a Host has to send a WRITE IO to a ‘remote’ DataCore Server (where the IO Path is significantly distant compared to the other ‘local’ DataCore Server), then the WAIT times accrued by having to send the IO not only across the SAN to the remote DataCore Server, but for the remote DataCore Server to mirror back to the local DataCore Server and then for the mirror write to be acknowledged from the local DataCore Server to the remote DataCore Server and finally for the acknowledgment to be sent to the Host back across the SAN, can be significant.
The benefits of being able to use all Paths to all DataCore Servers for all Virtual Disks are not always clear cut. Testing is advised.
For Preferred Path settings it is stated in the SANsymphony Help:
A preferred front-end path setting can also be set manually for a particular virtual disk. In this case, the manual setting for a virtual disk overrides the preferred path created by the preferred server setting for the host.
So for example, if the Preferred Server is designated as DataCore Server A and the Preferred Paths are designated as DataCore Server B, then DataCore Server B will be the ‘Active Optimized’ Side not DataCore Server A.
In a two-node Server group there is usually nothing to be gained by making the Preferred Path setting different to the Preferred Server setting and it may also cause confusion when trying to diagnose path problems, or when redesigning your DataCore SAN with regard to Host IO Paths.
For Server Groups that have three or more DataCore Servers, and where one (or more) of these DataCore Servers shares Mirror Paths between other DataCore Servers setting the Preferred Path makes more sense.
So for example, DataCore Server A has two mirrored Virtual Disks, one with DataCore Server B, and one with DataCore Server C and DataCore Server B also has a mirrored Virtual Disk with DataCore Server C then using just the Preferred Server setting to designate the ‘Active Optimized’ side for the Host’s Virtual Disks becomes more complicated. In this case the Preferred Path setting can be used to override the Preferred Server setting for a much more granular level of control.
Refer to the Preferred Servers and Preferred Paths sections in Port Connections and Paths.
B: Reclaiming Storage from Disk Pools
How Much Storage will be Reclaimed?
This is impossible to predict.
SANsymphony can only reclaim Storage Allocation Units that have no block-level data on them. If a Host write its data ‘all over’ its own filesystem, rather than contiguously, the amount of storage that can be reclaimed may be significantly less than expected.
Defragmenting Data on Virtual Disks
It may be possible to use a Host’s own defragmentation tools to consolidate data spread out all over the host’s filesystem but care should be taken as even more storage may be allocated while the existing data is defragmented.
Once any defragmentation is completed then additional steps will need to wipe the ‘free’ filesystem space on the host and then use SANsymphony’s ‘Manual Reclamation’ feature – see next.
Notes on SANsymphony's Reclamation Feature
Automatic Reclamation
SANsymphony checks for any ‘zero’ write I/O as it is received by the Disk Pool and keeps track of which block addresses they were sent to. When all the blocks of an allocated SAU have received ‘zero’ write I/O, the storage used by the SAU is then reclaimed.
Mirrored and replicated Virtual Disks will mirror/replicate the ‘zero’ write I/O so that storage can be reclaimed on the mirror/replication destination DataCore Server in the same way.
Manual Reclamation
SANsymphony checks for ‘zero’ block data by sending read I/O to the storage. When all the blocks of an allocated SAU are detected as having ‘zero’ data on them, the storage used by the SAU is then reclaimed.
Mirrored Virtual Disks will receive the manual reclamation ‘request’ on all DataCore Servers involved in the mirror configuration at the same time and each DataCore Server will read from its own storage.
The Manual reclamation ‘request’ is not sent to replication destination DataCore Servers from the source. Replication destinations will need to be manually reclaimed separately.
Reclaiming Storage on the Host using SCSI UNMAP/TRIM
SCSI UNMAP/TRIM commands issued by the Host can be used to trigger SANsymphony's ‘Automatic Reclamation’ function. To determine if this feature is enabled on your Windows Host, use the inbuilt ‘fsutil’ command’s ‘File-delete notification’ feature.
Example:
fsutil behavior query disabledeletenotify
Windows 2012 and later Hosts only (refer to SCSI UNMAP).
Reclaiming Storage on the Host Manually
For versions of Windows Hosts that do not support UNMAP, have UNMAP disabled or are using Virtual Disks served from older versions of SANsymphony that do not support SCSI UNMAP, a suggestion would be to use Microsoft’s sdelete command to write zeroes directly to the filesystem and trigger SANsymphony's ‘Automatic Reclamation’ function.
Be careful when running the sdelete command directly on Cluster Shared Volume (CSV) Disks. Do not run sdelete directly on a CSV, use the subst command to assign a virtual drive to the CSV mount point and then run sdelete on the virtual drive.
Example:
subst G: "C:\ClusterStorage Volume2
sdelete64.exe -z G:
C: Configuring Microsoft’s own MPIO for SANsymphony Virtual Disks
For Windows Hosts that are not using DataCore Windows Integration Kit but using Microsoft's own 'built-in' MPIO the following steps are required for Windows MPIO to work with SANsymphony Virtual Disks.
-
On the Windows Host server, install the ‘Multipath I/O’ Feature.
A reboot of is not usually needed after installing the Multipath I/O feature, but if prompted by Windows to reboot, please reboot before continuing.
-
Open Microsoft’s 'Multipath I/O Configuration Tool' (mpiocpl.exe) and select the 'MPIO Devices' tab.
-
Enter the string "DataCoreVirtual Disk" in the 'Add MPIO Support' window.
Please enter the string exactly as it appears above. The Vendor and Product IDs are case sensitive and there must only space between the strings 'Virtual' and ‘Disk’.
If the configuration was ever upgraded from ‘SANsymphony 7.x’ or ‘SANmelody’, additional IDs should be entered.
-
Click OK. Reboot when prompted.
It is possible to enter more than one Vendor/Product ID and ignore the reboot request until the last entry has been added.
Verifying MPIO is Configured for SANsymphony Virtual Disks
For Windows Hosts that are not using DataCore Windows Integration Kit but using Microsoft's own 'built-in' MPIO. This section shows how to verify that the settings made in the previous section are working as expected.
Via Windows Device Manager
-
Under ‘Disk drives’ locate a 'DataCore Virtual Disk Multi-Path Disk Device'; right- click the device and select 'Properties' from the context menu.
Each Virtual Disk served to the Host will create a single 'DataCore Virtual Disk Multi-Path Disk Device' regardless if the Virtual Disk is mirrored (or not) and regardless of how many paths the Virtual Disk is served to/from i.e. for 3 Virtual Disks, expect to see 3 DataCore Virtual Disk Multi-Path Disk Device' entries.
-
Select the ‘MPIO’ tab.
The example above indicates that there are two paths to the Virtual Disk.
Previous Changes
| Section(s) | Content Changes | Date |
|---|---|---|
| Windows Host Settings – MPIO-specific parameters |
Updated Added an important note that for Windows 2019, the largest possible value for the DiskMaxTimeout value is 60. |
April 2021 |
| Windows Host Settings – MPIO-specific parameters | Updated
This section has been updated. For existing users, please check to make sure your Windows hosts are using the recommended settings. DataCore are now recommending that MPIOs PathVerificationState setting is ‘enabled’ as this has been shown to improve reliable ‘failback’, without any effect on performance, for large MPIO configurations. |
January 2021 |
| General | Updated
This document has been reviewed for SANsymphony 10.0 PSP 11. No additional settings or configurations are required. |
|
| Windows Host Settings – MPIO Parameters | Updated
Added a link to Microsoft’s own technical pages for references about the registry settings that DataCore expect (on a Host) when using either DataCore Windows Integration Kit MPIO component or Microsoft’s own MPIO implementation and DataCore Virtual Disks. |
June 2020 |
| Compatibility lists - all | Updated
Updated notes for Windows 2019 Hosts. |
April 2020 |
| The DataCore Server settings - Operating System Type | Updated
Updated notes for Windows 2019 Hosts. |
|
| General | Updated
This document has been reviewed for SANsymphony 10.0 PSP 9. No additional settings or configurations are required. |
October 2019 |
| Compatibility Lists - All |
Added Updated to include Windows 2019. |
July 2019 |
| The DataCore Server’s settings – Port Roles |
Updated The DataCore Server’s settings – Port Roles |
|
| General |
Removed All information regarding SANsymphony-V 9.x as this version is end of life (EOL). Refer to End of life notifications for DataCore Software products for more information. |
|
| Appendix B - Reclaiming storage from Disk Pools |
Updated Reclaiming storage on the Host manually. Added an important note about how to safely use sdelete when using Cluster Shared Volumes (CSV). |
June 2019 |
| The Windows Host Settings |
Updated Microsoft Cluster specific configuration settings Two new subsections have been added:
|
May 2018 |
| General |
Updated This document has been reviewed for SANsymphony 10.0 PSP 7. No additional settings or configurations are required. |
February 2018 |
| Appendix B – Configuring Disk Pools |
Removed The information here has been removed as it is now superseded by the information in: The DataCore Server - Best Practice Guidelines What was previously 'Appendix C' has now been moved to 'Appendix B' and so on. |
|
| Known Issues |
Updated Windows MPIO and DataCore MPIO (including DataCore WIK). Links for both the Windows Server 2016 and 2012 (R2-only) updates have been added and updated respectively. The changes to the information are below: Microsoft's multipath bus driver (MPIO.sys) may not failover if two or more paths from a Host to a Virtual Disk fail at the same time, or if the same Virtual Disk for two or more paths is unavailable. Windows 2012 (R2 only) and Windows 2016 Hosts: Microsoft have issued Windows Updates that fix this problem with their MPIO.sys driver. Windows 2016 - June 27, 2017—KB4022723 (OS Build 14393.1378) The specific fix is documented as "Addressed issue where you may lose access to storage disks when there are still available paths if there is an error on one of the multipath I/O paths." Windows 2012 - July 11, 2017—KB4025336 (Monthly Rollup) This July 11 KB includes everything from the June 27, 2017—KB4022720 (Preview …) where the specific fix is documented as "Addressed an issue where MPIO failover stops after a disk has been surprise removed, identified by Event ID 157: "Disk X has been surprised removed" when there are still viable paths to use. Scenario may occur when the newly selected path belongs to the disk that has been surprised removed." Windows 2008 and Windows 2012 (non-R2) Hosts: No fix from Microsoft is planned for either of these versions of Windows Server. |
September 2017 |
| Known Issues |
Updated Windows MPIO and DataCore MPIO (including DataCore WIK) Microsoft's multipath bus driver (MPIO.sys) may not failover if two or more paths from a Host to a Virtual Disk fail at the same time, or if the same Virtual Disk for two or more paths is unavailable. Windows 2012 and 2016 Hosts: Microsoft are issuing a fix – see June 27, 2017—KB4022720 (Preview of Monthly Rollup) "Addressed an issue where MPIO failover stops after a disk has been surprise removed, identified by Event ID 157: "Disk X has been surprised removed" when there are still viable paths to use. Scenario may occur when the newly selected path belongs to the disk that has been surprised removed." Windows 2008 Hosts: No fix is planned. See the full Known Issues description in this document on how to configure Windows 2008 Hosts with MPIO/WIK. |
July 2017 |
| Compatibility Lists - DataCore Windows Integration Kit (WIK) |
Added Compatibility Lists – VSS Hardware Provider Windows 2016 hosts are Qualified when using SANsymphony 10.0 PSP 6 or greater using DataCore's WIK 4.0 or greater. |
May 2017 |
| Appendix D - How to configure Microsoft's own 'built-in' MPIO |
Added Information regarding how to set the correct Vendor/Product ID when using Microsoft's own MPIO, including information on how to verify that MPIO has been set up correctly. |
|
| Compatibility Lists - DataCore MPIO for Windows |
Updated Only 'Round Robin with subset' or 'Failover only' MPIO Policies have been tested. |
|
| Compatibility Lists - DataCore MPIO for Windows |
Removed DataCore MPIO is end of life and all versions of the Windows Operating System that this version was qualified on are also End of life. Therefore all the compatibility list information for this product has been removed. Please use the MPIO component in the 'DataCore Windows Integration Kit' instead. |
|
| Compatibility lists |
Added Windows Offloaded Data Transfers (ODX) Windows SCSI UNMAP |
April 2017 |
| The Windows Host's Settings – Microsoft Cluster Settings | Added
Added instructions to set the Set '$cluster .QuorumArbitrationTimeMax' to 60 seconds. |
|
| Known Issues |
Added Known Issues - Affects Windows 2008, 2012 and 2016 Hosts 16 GB QLogic Fibre Channel Host Bus Adaptors Do not use driver version 9.1.17.21 with firmware older than 08.03.00 when connecting to DataCore Server Front-end ports using SANsymphony-V versions 10.0 PSP 4 Update 1 or earlier (including versions 9.0 PSP 4 Update 4 and earlier) as in some cases this firmware on the Host can cause the DataCore Server to crash. 2 or 4 GB QLogic Fibre Channel Host Bus Adaptors Do not use driver versions 9.0.1.12 or 9.0.2.11 as they may cause unexpected disconnections from the DataCore Server. These were both previously documented in 'Known Issues - Third Party Hardware and Software'. |
|
| Known Issues |
Removed When choosing a preferred Server setting for Windows Hosts with ALUA enabled, do not select 'All' setting when using SANsymphony 10.0.4.x or greater Choose an explicit DataCore Server (or leave as 'Auto Select') as in some cases when the 'ALL' setting is used, failover may not work as expected when one of the DataCore Servers is stopped. The root cause of this is now understood and so has been superseded by the known issues that were added in March 2017. Microsoft's multipath bus driver (MPIO.sys) may not failover if two or more paths from a Host to a Virtual Disk fail at the same time, or if the same Virtual Disk for two or more paths is unavailable. Even with the 'ALL' setting is used, as long as there is only one FE connection for a mirrored vDisk to each DataCore Server, failover will work as expected. |
|
| Known Issues |
Added Microsoft's multipath bus driver (MPIO.sys) may not failover if two or more paths from a Host to a Virtual Disk fail at the same time, or if the same Virtual Disk for two or more paths is unavailable. |
March 2017 |
| Compatibility lists - DataCore MPIO for Windows |
Updated All previously 'Supported' entries have been marked 'Supported (EOL)' for those users that are still using old versions of Windows with this version of DataCore's MPIO to indicate what was compatible when the product was officially End of Life. Entries that were marked as 'not qualified' have now been changed to 'not supported' as DataCore will not be able to accept self-qualification of an End-of-Life product. Otherwise all statements regarding support for end users using End-of-Life and Not Supported combinations still apply. |
|
| VSS compatibility lists |
Added Includes Microsoft's VSS Provider and DataCore's VSS Provider (via the HIK). |
January 2017 |
| The Windows Hosts Settings |
Added Added notes for Windows 2016 Hosts regarding Operating System type. |
|
| Appendix C – Reclaiming Storage |
Added Added note that Windows 2016 Hosts are included for SCSI UNMAP. |
|
| Microsoft Windows compatibility and MPIO compatibility lists |
Updated The table originally used in the Microsoft Windows compatibility section was not needed as the separate MPIO compatibility lists are more specific. This entire table has been removed. |
|
| Microsoft Windows compatibility and MPIO compatibility lists |
Initial Publication: Added Added notes for Windows Server 2016. |
December 2016 |
| Appendix C - Reclaiming storage |
Initial Publication: Updated Automatic and Manual reclamation These two sections have been re-written with more detailed explanations and technical notes. The most recent version of this document is available on DataCore Support. Included from previous documentation:
|