text:
Uploaded by techgig
saveSave mpio For Later
PCinfo
DxDiag
Intel® System Identification Utility - Identify Your Product
A109 Flashing Procedure
G Series ASIO Driver Installation Guide(Windows)
TS-x59Pro+TS-x39ProII+_dataSheet
asdm_lb
Dell Ha Exchange 2007
Action Point Quick Start Guide
Soft Install
How to Implement Load Balancing to Distribute Workload - CodeProject
25xxx Usb Manual
Libro El Trueno de La Justicia
vmwareinter-120123024809-phpapp02
Building Example 2 Mini Sumo Robot
JSEA_2013013009475515
Windows Server High Availability with Microsoft MPIO
www.Microsoft.com/MPIO
A growing number of organizations require that their data be available 24x7, year round. To meet this
requirement, centralized storage must be readily available and immune to outages at all times .The
Microsoft Multipath I/O (MPIO) framework provides support for multiple data paths to storage to improve
fault tolerance of connection to storage, and may in some cases provide greater aggregate throughput
by using multiple paths at the same time.
This whitepaper is intended for the following groups:
• The IT executive who is responsible for ensuring data is highly reliable and available and
makes the relevant procurement and evaluation decisions. The first half of this paper focuses upon the
executive, providing an overview of the problem and the Microsoft implemented solution.
• The storage administrator who is ultimately responsible for ensuring that an organization's data
remains highly available. The second half of the paper addresses the needs of the storage administrator
and includes a trouble shooting section
• Storage vendors who target Multi-Path solutions using the Microsoft MPIO framework in
Windows Sever 2008 and Windows Server 2003 family of operating systems. .
Microsoft® Windows® Server 2008 White Paper
The information contained in this document represents the
current view of Microsoft Corporation on the issues discussed
as of the date of publication. Because Microsoft must respond
to changing market conditions, it should not be interpreted to be
a commitment on the part of Microsoft, and Microsoft cannot
guarantee the accuracy of any information presented after the
date of publication.
This document is for informational purposes only. MICROSOFT
MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO
THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility
of the user. Without limiting the rights under copyright, no part
of this document may be reproduced, stored in or introduced
into a retrieval system, or transmitted in any form or by any
means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written
permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks,
copyrights, or other intellectual property rights covering subject
matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents,
trademarks, copyrights, or other intellectual property.
© 2008 Microsoft Corporation. All rights reserved.
Microsoft, Windows, Windows Server and Windows Vista are
either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein
may be the trademarks of their respective owners.
Contents..................................................................................................................................................1
High Availability Solutions....................................................................................................................3
Application Availability through Failover Clustering...............................................................................3
Storage Redundancy through RAID .....................................................................................................3
Storage Availability through MPIO........................................................................................................3
MPIO Solutions.......................................................................................................................................5
Multipath solutions in Windows Server 2008 ....................................................................................5
Making MPIO-Based Solutions Work....................................................................................................7
Device Discovery and Enumeration......................................................................................................7
Unique Storage Device Identifier..........................................................................................................8
Dynamic Load Balancing .....................................................................................................................8
Error Handling, Failover and Recovery.................................................................................................8
Differences in load balancing terminology:........................................................................................9
Differences in failover technology:.....................................................................................................9
The Windows Storage Stack and Drivers .........................................................................................11
Storage Stack and Device Drivers .....................................................................................................11
DSM Management...........................................................................................................................13
MPIO Drivers in Windows Server 2008...............................................................................................13
MPIO DSM .........................................................................................................................................13
Device Initialization..........................................................................................................................14
MPIO device discovery ......................................................................................................................14
Request Handling............................................................................................................................15
Error Handling.................................................................................................................................16
Details of the Windows Server 2008 Microsoft DSM.......................................................................16
Using MPIO on Windows Server 2008 ...............................................................................................18
Adding MPIO Support on Windows Server 2008................................................................................18
MPIO Configuration and DSM installation...........................................................................................21
How to configure the Load Balance policy for a LUN:.........................................................................26
Troubleshooting Examples:.................................................................................................................29
Highly Available Storage: Multipath Solutions in Windows Server 2008 and Windows Server 2003 1
Verify whether the storage is correctly setup with MPIO.................................................................29
Using mpclaim.exe to configure MPIO on Windows Server 2008....................................................31
Add MPIO support for FC device(s):................................................................................................31
Add MPIO support for iSCSI devices:..............................................................................................32
Add MPIO support for all devices that are multipathed:...................................................................32
Remove MPIO support for FC device(s):.........................................................................................32
Remove MPIO support for iSCSI devices:.......................................................................................32
Remove MPIO support for all devices on the system:.....................................................................33
Installation of MPIO on Server Core installations of Windows Server
2008........................................................................................................................................................34
..............................................................................................................................................................35
To install MPIO on server core:.......................................................................................................35
To remove the MPIO feature on server core:
........................................................................................................................................................35
Access the MPIO control panel on server core:...............................................................................35
Appendix A – Script Example : Query the MPIO Policy for a device................................................36
Appendix B – MPIO & DSM Configuration and best practices ........................................................38
To search for hardware ID's registered with more than one DSM:..................................................39
To add a hardware ID to be used with MPIO:..................................................................................40
Appendix C – Determining the Hardware ID to be used with MPIO..................................................42
Appendix D – Enabling software tracing for MPIO............................................................................45
Appendix E - MPIO timers....................................................................................................................47
Appendix F – Acronyms:.....................................................................................................................48
Conclusion ...........................................................................................................................................49
Resources.............................................................................................................................................50
High Availability Solutions
Keeping mission-critical data continuously available has become a requirement over a wider range
of customer segments from small business to datacenter environments. Enterprise environments
using Windows Server require 99.999 percent uptime for all key workloads including file server,
database, messaging and other line of business applications. This level of availability can be
difficult and very costly to achieve and it requires that redundancy be built in at multiple levels:
storage redundancy, backups to separate recovery servers, server clustering, and redundancy of
the physical path components.
Application Availability through Failover Clustering
Clustering is the use of multiple servers, Host Bus Adapters (HBA's), and storage devices that work
together to provide users with high application availability. If a server experiences a hardware
failure, or is temporarily unavailable, end users are still able to transparently access data or
applications on a redundant cluster node. In addition to providing redundancy at the server level,
Clustering can also be used as a tool to minimize the downtime required for patch management
and hardware maintenance. Clustering solutions require software that enables transparent failover
between systems. Windows Server Failover Clustering (WSFC) or Microsoft Cluster Server (MSCS)
as it was previously known is one such solution that is included with the Enterprise Edition and
Datacenter versions of Microsoft Windows Server 2008 and Windows Server 2003.
Storage Redundancy through RAID
High availability solutions based on redundant arrays of independent disks (RAID) have been in use
with mainframe equipment for several decades, and have been supported in the Windows
operating system since the first release of Windows NT. RAID solutions provide protection of data
through the use of redundant disks, which can be configured for both fault tolerance and/or
improved performance.
Storage Availability through MPIO
The Microsoft MPIO framework allows Windows to manage and efficiently use up to 32 paths from
storage devices and applications/operating systems. Although both MPIO and WSFC result in high
availability and improved performance, they are not equivalent concepts. While clustering provides
high application availability and tolerance of server failure, MPIO provides fault tolerant connectivity
to storage. By employing MPIO and WSFC together as complimentary technologies users are able
to mitigate the risk of a system outage at both the hardware and application levels.
Note: When using the iSCSI Software Boot initiator, a maximum of 2 paths to the boot volume are
MPIO provides the logical facility for routing I/O over redundant hardware paths connecting server
to storage. These redundant hardware paths are made up of components such as the cabling, Host
Bus Adapters (HBA's), Switches, and Storage Controllers and possibly even power. MPIO solutions
logically manage these redundant connections so that I/O requests can be rerouted in the event
that a component along one path fails.
As more and more data is consolidated on Storage Area Networks (SAN's), the potential loss of access
to storage resources is unacceptable. To mitigate this risk, high availability solutions, like MPIO, have
now become a requirement.
MPIO Solutions
MPIO is a Microsoft-provided framework that allows storage providers to develop multipath
solutions that contain the hardware specific information needed to optimize connectivity with their
storage arrays. These modules are called Device Specific Modules (DSM's). The concepts around
DSM's are explored in greater detail later on within this document.
The Microsoft MPIO solution is protocol independent and can be used with FC, iSCSI, parallel
SCSI, and Serial Attached SCSI (SAS) interfaces on the following operating systems
• Windows Server 20081
Multipath solutions in Windows Server 2008
With Windows Server 2008, an IT storage administrator has several of choices while deploying a
MPIO solution. These include:
• Deploy the Microsoft MPIO framework and use a storage vendor provided DSM for
Windows Server 2008 in a FC, iSCSI, or SAS shared storage configuration
• Deploy the Microsoft MPIO framework using the Microsoft DSM (MSDSM) which is a
generic DSM provided for Windows Server 2008 in a FC, iSCSI, or SAS shared storage
The notable enhancements to the Microsoft MPIO solution in Windows Server 2008 include:
• As previously discussed, a complete solution that an IT department can deploy
along with the appropriate hardware
• Support for Asymmetrical Logical Unit Access (ALUA) controller model as defined
in SCSI Primary Commands-3 (SPC-3).
• Support for storage arrays that follow the Active/Active controller model. This
support allows for using all available I/O paths when they are healthy.
Note: When using the MSDSM, storage that implements an Active/Active storage scheme
but does not support ALUA will default to use the "Failover-Only" Load Balance policy,
although a different policy may be chosen later.
• Multipathing solutions are not eligible to receive logo qualification unless they
adhere to the MPIO framework. IT administrators should verify the logo status of array
vendor solutions. The following link lists solutions logoed with vendor storage products.
Failover Clustering in Windows Server 2008 does not support the use of parallel SCSI storage
For additional information on logo requirements please refer to the WinQual Logo Site
(https://winqual.microsoft.com/default.aspx)
With Windows Server 2003, an IT storage administrator can:
• Deploy a solution available only from vendors for a SAN. The storage array partner
builds their DSM and offers the solution using the Microsoft MPIO framework that Microsoft
makes available to partners. On the Windows Server 2003 platform, the partner provides a
Device Specific Module (DSM) that understands the nuances of the vendor hardware and
plugs into the Microsoft provided MPIO architecture.2
• Deploy the Microsoft MPIO DSM for iSCSI included in the Microsoft iSCSI Software
Initiator package
This joint solution allows storage partners to design hardware solutions that are integrated with the
Windows operating system. Compatibility with both the operating system and other partner
provided storage devices is ensured through the Windows Logo program tests to help ensure
proper storage device functionality. This ensures a highly available multipath solution using
Microsoft MPIO which offers supportability across Windows OS implementations.
Customers should refer to guidance from their hardware storage array partner on which DSM to
use with their storage. Multipath solutions are supported as long as a DSM is implemented in line
with Logo requirements for MPIO. Most Multipath solutions for Windows today do use the MPIO
architecture and use a DSM provided by the storage IHV. Customers may use the Microsoft DSM
provided by Microsoft in Server 2008 if supported by storage partner as well. Customers should
refer to their storage array partner for guidance on which DSM to use with a given storage array as
well as the optimal configuration.
Multipath software suites available from storage IHV's typically provide an additional value add
beyond the implementation of the MSDSM as the software typically also provides auto
configuration, heuristics for specific storage arrays, as well as statistical analysis, and integrated
management, It's generally recommended to use the DSM provided by the hardware storage array
partner to achieve optimal performance since the storage array partner can make more advanced
path decisions in their DSM specific to their array.
On Microsoft Windows Server 2003, the storage provider will redistribute the MPIO framework with the storage provider's DSM.
Making MPIO-Based Solutions Work
The Windows operating system relies on the Plug and Play (PnP) Manager to dynamically detect
and configure hardware (such as adapters or disks), including hardware used for high
availability/high performance Multipathing solutions.
Note: A reboot is required when the MPIO feature is first installed.
Device Discovery and Enumeration
MPIO/Multipath drivers cannot work effectively or efficiently until it discovers, enumerates and
configures different devices that the OS sees through redundant adapters into a logical group. We
will briefly outline in this section as to how MPIO works along with DSM in discovering and
configuring the devices.
Without any multipath driver the same devices through different physical path would look like totally
different devices thereby leaving room for data corruption. Figure1 depicts this scenario
Server Server
Without multipathing software, With multipathing software, the
the host incorrectly interprets server correctly interprets the
the two paths as leading to two two paths as leading to the
Figure 1: What the operating system
storage units "sees" with and withoutsameMPIO
The following are the sequence of steps that the device driver stack walks through in discovering,
enumerating and grouping the physical devices, device paths into a logical set. (Assuming a
scenario where a new device is being presented to the server)
1. New device arrives.
2. PnP manager detects the arrival of this device.
3. MPIO driver stack is notified of this device arrival (it will take further action if it is a
supported MPIO device).
4. MPIO driver stack creates a pseudo device for this physical device.
5. MPIO driver walks through all the available DSM's to find out which vendor specific
DSM can claim this device. After a DSM claims a device it is associated only with the DSM
that claimed it.
6. The MPIO driver, along with the DSM, makes sure the path to this device is
connected, active, and ready for IO.
If a new path for this same device arrives, MPIO then works with the DSM to determine whether
this device is the same as any other claimed device. It then groups this physical path for the same
device into a logical set called multipath group.
Unique Storage Device Identifier
For dynamic discovery to work correctly, some form of identifier must be identified and obtainable
regardless of the path from the host to the storage device. Each logical unit must have a unique
hardware identifier. The MPIO driver package does not use disk signatures placed in the data area
of a disk for identification purposes by software. Instead, the Microsoft provided generic DSM
manufactures a unique serial number from the hardware data reported by standard SCSI INQUIRY
commands. MPIO also provides for optionally using device manufacturer assigned unique serial
Since not all storage IHV's assign their devices a unique hardware serial number, Microsoft
includes in its sample generic DSM source code a means of deriving one, using other SCSI
INQUIRY data. Alternatively, vendor-specific mechanisms can be implemented in IHV's DSM.
Dynamic Load Balancing
Load balancing, the redistribution of read/write requests for the purpose of maximizing throughput
between server and storage device, is especially important in high workload settings or other
settings where consistent service levels are critical. Without Multi Path I/O software, a server
sending I/O requests down several paths may operate with very heavy workloads on some paths
while others are underutilized.
The Microsoft MPIO software supports the ability to balance I/O workload, without administrator
intervention. MPIO determines which paths to a device are in an active state and can be used for
load balancing. Each vendor's load balancing policy (which may use any of several algorithms,
such as round robin, the path with the fewest outstanding commands, or a vendor unique algorithm)
is set in the DSM. This policy determines how the I/O requests are actually routed.
Note: In addition to the support for load balancing provided by MPIO, the hardware used
must support the ability to use multiple paths at the same time rather than just fault
Error Handling, Failover and Recovery
The MPIO driver, in combination with the DSM, supports end-to-end path failover. The process of
detecting failed paths and recovering from the failure, like load balancing, is automatic, usually fast,
and completely transparent to the IT organization. The data ideally remains available at all times.
Not all errors result in failover to a new path. Some errors are temporary and can be recovered
using a recovery routine in the DSM; if recovery is successful, MPIO is notified and path validity
checked to verify that it can be used again to transmit I/O requests.
When a fatal error occurs, the path is invalidated and a new path is selected. The I/O is resubmitted
on this new path without requiring the Application layer to resubmit the data.
Differences in load balancing terminology:
There are 2 primary types of load balancing technology referred to within Microsoft Windows. This
whitepaper discusses the use of the first only.
1. MPIO Load Balancing – This type of load balancing supported by MPIO is the use of
multiple data paths between server and storage to provide greater throughput of data then could be
achieved with only one connection.
2. Network Load Balancing (NLB) – This is a Microsoft Windows Cluster technology that
provides load balancing of network interfaces to provided greater throughput across a network to
the server, and is most typically used with Internet Information Server (IIS).
Differences in failover technology:
When speaking about data path failover, such as the failover of HBA or iSCSI connections to
storage, the following main types of failover are available:
1. MPIO based Fault Tolerant (FT) failover – In this scenario, multiple data paths to the
storage are configured, and in the event that one path fails, the HBA or NIC is able to failover to the
other path, and re-send any outstanding IO.
a. For a server that has one or more HBA or NIC, MPIO offers support for redundant switch
fabrics or connections from the switch to the storage array.
b. For a server that has more than one HBA or NIC, MPIO also offers protection against the
failure of one of those adapters within the server directly.
2. MPIO based Load Balancing – In this scenario, multiple paths to storage are also defined,
however the DSM is able to balance the data load to maximize throughput. This configuration can
also employ FT behavior so that if one path fails, all data would go over an alternate path.
In some hardware configurations you may have the ability to perform dynamic firmware updates on
the storage controller, such that a complete outage is not required for firmware updates. This
capability is hardware dependant and requires (at a minimum) that more than one Storage
Controller be present on the storage so that data paths can be moved off of a storage controller for
upgrades.
3. The third type of failover, such as Windows Server Failover Clustering (WSFC). This type
of configuration offers resource failover at the application level from one cluster server node to
another. This type of failover is more invasive than storage path failover in that it will require client
applications to reconnect after failover, and resend data from the application layer. This method can
be combined with scenarios 1 and/or 2 above to further mitigate risk exposure to different types of
hardware failures.
Different behaviors are available depending on the type of failover technology used, and whether it
is combined with a different type of failover or redundancy. Consider the following scenarios:
Scenario 1: Using MPIO without clustering:
This scenario provides for either a fault tolerant connection to data, or a load balanced
connection to storage. Since this layer of FT operation protects only the connectivity
between the server and storage, it does not provide protection against server failure.
Scenario 2: Combining the use of MPIO in fault tolerant mode with WSFC:
This configuration provides the following advantages:
• If a path to the storage fails, MPIO can use an alternate path without requiring client
application reconnection.
• If an individual server experiences a critical event such as hardware failure, the application
managed by WSFC is failed over to another cluster node. While this does require client
reconnection, the time to restoration of service may be much shorter than that required for replacing
the failed hardware.
Scenario 3: Combining the use of MPIO in load balancing mode with WSFC:
This scenario provides the same benefits as scenario 2 plus:
• During normal operation, multiple data paths may be employed to provide greater
aggregate throughput than one path could provide.
Scenarios 2 and 3 may also be used as an aid to software update management to reduce total
downtime perceived by clients by making the managed application available again on a different
server while one is updated.
Highly Available Storage: Multipath Solutions in Windows Server 2008 and Windows Server 2003
The Windows Storage Stack and Drivers
For the operating system to correctly perform operations that relate to hardware, such as addition
or removal of devices or transferring I/O requests from an application to a storage device, the
correct device drivers must be associated with the device. All device-related functionality is initiated
by the operating system, but under direct control of subroutines contained within each driver. These
processes are considerably complicated when there are multiple paths to a device. The MPIO
software prevents data corruption by ensuring correct handling of the driver associated with a single
device that is visible to the operating system through multiple paths. Data corruption is likely to
occur because when an operating system believes two separate paths lead to two separate storage
volumes, it does not enforce any serialization or prevent any cache conflicts. Consider what would
happen if NTFS tries to initialize its journal log twice on a single volume.
Storage Stack and Device Drivers
Storage architecture in Windows consists of a series of layered drivers, as shown in Figure 2. (Note
that the application and the disk subsystem are not part of the storage layers.) When a device such
as a storage disk is first added in, each layer of the hierarchy is responsible for making the disk
functional (such as by adding partitions, volumes and the file system (FS)). The stack layers below
the broken line are collectively known as the device stack and deal directly with managing storage
I/O Subsystem Sends I/O request to FS
Imposes file structure on
File System raw volumes
Volume Manages software
Presents volumes (C:, D:)
Volume to users; supports basic
Manager and dynamic disks (RAID)
Partition Manages disk partitions
Manages a specific device
Port: Manages a specific Class type, such as disks, tapes
transport (SCSIport for SCSI,
Storport for RAID , FC, iSCSI, Miniport: Vendor supplied,
SAS, etc) Port Miniport functionally linked to specific
port driver; manages
hardware specific details
Disk Subsystem
Figure 2. The Windows Storage Stack
Device drivers manage specific hardware devices, such as a disks or tapes, on behalf of the
operating system.
Port Drivers
Port drivers manage different types of transport, depending on the type of adapter (USB, iSCSI or
Fibre Channel (FC), for example) in use. Historically, one of the most common port drivers in the
Windows system was the SCSIport driver. In conjunction with the class driver, the port driver
handles PnP and power functionality. Port drivers manage the connection between the device and
the bus. Windows Server 2003 introduced a new port driver, Storport, which is better suited to high-
performance, high-reliability environments and is typically much more commonly used than
SCSIport today.
Miniport Drivers
Each storage adapter has an associated device driver known as a "miniport." This driver
implements only those routines necessary to interface with the storage adapter's hardware. A
miniport partners with a port driver to implement a complete layer in the storage stack, as shown in
Class drivers manage a specific device type. Class drivers are responsible for presenting a unified
disk interface to the layers above (for example, to control read/write behavior for a disk). The class
driver manages the functionality of the device. Class drivers (like port and miniport drivers) are not
a part of the MPIO driver package per se; however, the Plug and Play disk class driver, disk.sys, is
used as part of the Multipathing solution, since the class driver controls the disk add/removal
process and I/O requests pass through this driver to the MPIO bus driver (see "MPIO Drivers," the
following section).
The MPIO driver package consists of three multipath drivers: the port filter driver, the disk-driver
replacement, and the bus driver; all are implemented in the kernel mode of the operating system.
The MPIO driver package works in combination with the PnP Manager, the disk class driver, the
port driver, the miniport driver, and a device-specific module (DSM) to provide full Multipath
Multipath Port Filter Driver (mpsfltr)
The multipath port filter driver loads between the port driver and the class driver, and manages
information passed up the stack by the port drivers. The filter changes the default ID for disk
devices from the generic one of "GenDisk" to the MPIO specific "MPIODisk".
Multipath Disk Driver (mpdev.sys)
The multipath disk driver works as a parallel implementation to the existing class driver. Once a
device is identified and the DSM of a specific vendor is associated with it, mpdev.sys claims
ownership of the disk device object (the PDO) and prevents any other driver from being associated
with it. This directly prevents another driver from creating another device stack on the same LUN
and mounting a new file system—a process that would destroy the original file system and any data
on the LUN. Without this driver, this disk class driver would claim each instance of the disk devices,
creating multiple active paths to the device. This driver also notifies the MPIO bus driver of new
device arrivals.
Multipath Bus Driver (mpio.sys)
Bus drivers are responsible for managing the connection between the device and the host
computer. The multipath bus driver provides a "software bus (also technically termed a "root
bus")"—the conceptual analog to an actual bus slot into which a device plugs. It acts as the parent
bus for the multipath children (disk PDOs). As a root bus, mpio.sys can create new device objects
that are not created by new hardware being added into the configuration. The MPIO bus driver also
communicates with the other multipath drivers ( the MPIO port filter and MPIO class driver),
manages the PnP connection and power control between the hardware devices and the host
computer, and uses WMI to allow storage array partners to monitor and manage their storage and
associated DSMs.
DSM Management
Management and monitoring of the DSM can be done through WMI. On Windows Server 2008,
MPIO may be configured using the mpclaim.exe tool and additionally does include the needed WMI
code within the MPIO drivers.
MPIO Drivers in Windows Server 2008
On Windows Server 2008, some of these MPIO drivers have been integrated into the storage stack.
In particular
• The MPIO port filter driver mpspfltr.sys has been integrated into Storport.
• The Mpdev disk class driver functionality has been integrated into classpnp .
Note: In order to receive a Windows Logo, multipath solutions need meet the requirements of
the MPIO Framework. Storage partners that implement their own class driver (legacy
multipath) are not supported in Windows Server 2008
MPIO DSM
As explained earlier, a storage IHV's DSM incorporate knowledge of the IHV's hardware. A DSM
interacts with the MPIO driver. The MPIO DDK available from Microsoft includes source for a
generic DSM that Storage partners can modify. A DSM plays a crucial role in device initialization,
I/O request handling including I/O request error handling. These DSM actions are described further
in the following sections.
Device Initialization
Recall that MPIO allows for devices from different storage vendors to coexist, and be connected to
the same Windows Server 2008 based or Windows Server 2003 based system. This means a
single Windows server may have multiple DSM's installed. When a new eligible device is detected
via PnP, MPIO attempts to determine which DSM is appropriate to handle this particular device.
MPIO contacts each DSM, one device at a time. The first DSM to claim ownership of the device is
associated with that device and the remaining DSMs are not allowed a chance to press claims for
that already claimed device. There is no particular order in which the DSMs are contacted, one at a
time. The only guarantee is that the Microsoft generic DSM is always contacted last. If the DSM
does support the device, it then indicates whether the device is a new installation, or the same
device previously installed but which is now visible through a new path.
MPIO device discovery
Figure 2 showed the hierarchy of layered Windows drivers. Figure 3 on the following page
illustrates how devices and path discovery works with MPIO.
New device arrives (LUN)
Adapters/PCI bus discovers/detects the devices
PnP/Disk Manager
Port Driver – Creates the device and presents
device to MPIO driver
Walk through DSM modules installed/
available on the host No vendor
DSM claims it
Vendor specific DSM claims it
Should MS DSM claim the
ID of Vendor DSM that claims the device
device is associated with it
Is this path to the ID of Microsoft default DSM is
device already associated with this device NO
Group it under same psuedo node/ YES
device Create psuedo device
(it logically groups the path into path
set for this psuedo device)
Device will not be managed by MSDSM and is
Expose the pseudo device of the real device that OS detected (with multipath support) not exposed for access.
Figure 3. MPIO device discovery flowchart
Request Handling
When an application makes an I/O request to a specific device, the DSM that claimed the device
makes a determination, based on its internal load balancing algorithms, as to which path the
request should be sent.
If the I/O request fails, the DSM responsibilities include analyzing the failure to determine whether
to simply retry the I/O or to cause a failover to a new path or to return the error to the requesting
application. In case of a failover, the DSM determines what new path should be used. The actual
rebuild of the I/O and resubmission of the I/O is done by the Microsoft MPIO framework and is not
the responsibility of the DSM. The details of the DSM/MPIO interaction to make all of this happen
are beyond the scope of this document, and are given in the MPIO Driver Development Kit (DDK)
material available from Microsoft.
Details of the Windows Server 2008 Microsoft DSM
The Microsoft DSM provided as part of the complete solution in Windows Server 2008 includes
support for the following policies:
• Failover, where no load balancing is performed. The DSM will specify a primary
path and a set of standby paths. Primary path is used for processing device requests. If the
primary path fails, one of the standby paths will be used.. Any one of the available paths
could be used as primary path, and the remaining paths will be used as standby paths.
Note: With an array that supports ALUA, paths will typically be referred to as Active /
Optimized and Active Unoptimized rather than only as a Primary path.
Failback is the ability to dedicate I/O to a designated preferred path whenever it is
operational. If the preferred path fails, I/O will be directed to an alternate path, but will
automatically switch back to the preferred path, with some DSM assistance when it
becomes operational again.
• Round Robin Load balancing where the DSM will use all available paths for I/O in a
balanced, round robin fashion. This is the default policy chosen when the storage controller
follows the true Active-Active model and the management application does not explicitly
choose a load balancing policy.
• Round Robin with subset of paths is load balancing wherein the application will
specify a set of paths to be use in Round Robin fashion, and a set of standby paths. The
DSM will use paths from primary pool of paths for processing requests as long as at least
one of the paths is available. The DSM will use a standby path only when all the primary
paths fail. For example, given 4 paths – A, B, C, and D, A, B, and C are listed as primary
paths and D is standby path. The DSM will choose a path from A, B, and C in round robin
fashion as long as at least one of them is available. If all three fail, the DSM will start using
D, the standby path. If A, B, or C become available, DSM will stop using D and switch to
the available paths among A, B, and C.
• Dynamic Least Queue Depth Load Balancing where the DSM will route I/O to the
path with the least number of outstanding requests.
• Weighted Path load balancing where a weight is assigned to each path; the weight
indicates the relative priority of a given path. The larger the number the lower the priority.
The DSM will choose a path, among the available paths, with least weight.
Using MPIO on Windows Server 2008
This section is focused on the Storage Administrator and explains how to install, administer and
troubleshoot MPIO on Windows Server 2008.
Adding MPIO Support on Windows Server 2008
MPIO is an Optional Component (OC) in Windows Server 2008 and is not installed by default. To
install MPIO support on a Windows Server 2008 server, perform the following steps:
1. From Server Manager, select "Add Features" as shown in Figure 4.
Figure 4. Windows Server 2008 Add Features GUI
2. Select Multipath I/O as shown in Figure 5.
Figure 5 - Windows Server 2008 Features Selection for Installation GUI
3. Click Next.
Figure 6. Windows Server 2008 MPIO Feature Installation Confirmation GUI
4. Click Install as shown in Figure 6.
Figure 7. Windows Server 2008 MPIO Installation Progress GUI
5. Allow MPIO Installation to complete.
Figure 8. Windows Server 2008 MPIO Installation Results GUI
6. Click "Close" to finish the MPIO installation
MPIO Configuration and DSM installation
When MPIO is installed, the Microsoft provided DSM is also installed. An MPIO control panel is also
installed. This MPIO control panel can be used to:
• Configure MPIO functionality
• Install additional storage DSMs
The MPIO control panel is accessed from the classic view of the Control Panel as shown in Figure
9 on the next page.
Figure 9. Windows Server 2008 Control Panel Classic View showing MPIO Control Panel Applet
MPIO Configuration can also be launched from Administrative Tools as shown in Figure 10.
Figure 10. Windows Server 2008 Administrative tools showing MPIO administration applet
When the MPIO Control Panel applet is launched as shown in either Figure 9 or Figure 10, the
applet generates an MPIO Properties page as shown in Figure 11
Figure 11. MPIO Properties GUI
The MPIO Properties page has 3 tabs and by default, the MPIO-ed Devices Tab is selected.
The "MPIO-ed Devices" tab shows the hardware ID's of devices that will currently be managed by
MPIO whenever they are present. The decision is based on their hardware id (ie. Vendor+Product
string) matching one that is maintained by MPIO in its MPIOSupportedDeviceList (this is something
that every DSM specifies in its INF at the time of installation).
Figure 11 shows an example of a device is MPIO-ed.
The Add Button in Figure 11 allows for the administrator to specify another MPIO-ed device. Figure
12 shows the GUI generated when the Add tab in Figure 11 is clicked.
Figure 12 Specifying MPIO-ed devices GUI
Note: The Vendor and Product ID's needed in the "Add MPIO Support" dialog box shown above will
be provided by the Storage provider, and are specific to each type of hardware.
Referring back to Figure 11, recall that there are 3 tabs in the GUI. The first tab "MPIO-ed devices"
Is explained in previous sections.
The "Discover Multi-Paths" tab runs an algorithm for every device instance that is present on the
system and determines if multiple instances actually represent the same LUN (through different
paths). For such devices found, their hardware ids are presented for the Admin for MPIO'ing (they'll
get MSDSM support though).
Again, referring back to Figure 11, the "DSM Install" tab can be used to install DSMs provided by
the storage IHV.
Figure 13 DSM Install Tab
Many storage arrays which are active/active and SPC-3 compliant will work using the Microsoft
MPIO DSM. Some storage array partners also provide their own DSMs to use with the Microsoft
MPIO architecture. These DSMs may be installed using the DSM Install tab in the MPIO properties
Control Panel configuration utility:
IHV's are expected to build their package using the MPIO Development Kit version 1.21 or higher
from Microsoft. Many storage array partners provide their own installation package for their DSM.
For Windows Server 2003, this installation package includes the MPIO core binaries signed by
Microsoft. When such a package is run on Windows Server 2008, the operating system allows the
vendor DSM to be installed, but prevents the MPIO binaries already present in Windows Server
2008 from being updated by the package. Thus the end result of running the vendor installation
package is to preserve the core MPIO binaries already present in Windows Server 2008, but the 3rd
party provided DSM is added.
How to configure the Load Balance policy for a LUN:
MPIO LUN load balancing is integrated with Disk Management. To configure MPIO LUN load
balancing, start the Disk Management GUI
Figure 14 Disk Management
Figure 14 shows the Disk Management GUI. Right-Click the Desired disk (in this case C: ) to
change the policy for, and choose properties:
Figure 15 Device Properties Page
Click the MPIO tab in the Device Properties Page shown in Figure 15.
Figure 16 MPIO Device Properties Page
Figure 16 shows the resulting GUI. The Desired Load Balance Policy can be configured by
selecting the drop-down menu for Load Balancing Policy in Figure 16.
Figure 17 Load Balancing Drop Down dialog box
Figure 17 shows just the resulting drop down menu choices for Load Balancing. In this example,
"Fail Over Only" is selected.
Additional details about the currently configured DSM can be displayed by clicking the Details
button in Figure 16.
Note: When using a DSM other than MSDSM, the DSM vendor may use their own interface to
manage these policies.
Figure 18 DSM Details
Figure 18 shows the resulting DSM Details dialog
Note: For additional information on DSM Timer Counters please refer to appendix D.
Troubleshooting Examples:
In the example below, we use IBM 1742 storage
Verify whether the storage is correctly setup with MPIO
1. Click Start, in the search box, type "devmgmt.msc" (without quotes) and press
2. Click the View menu, and choose "Devices by connection"
a. Do you see the node: "Microsoft Multi-Path Bus Driver"?
b. Do you see the node: "Microsoft Multi-Path Device Specific Module"?
3. Expand each of the FC adapters that the IBM storage is connected through
a. Do you see the IBM device(s) show up under the HBA?
4. Click Start, point to Run, type "regedit" (without quotes) and press ENTER.
5. Expand HKLM\System\CurrentControlSet\Control and go to the MPDEV key
a. Do you see "IBM 1742 " listed in the MPIOSupportedDeviceList value?
6. Expand HKLM\System\CurrentControlSet\Services\msdsm\Parameters
a. Do you see "IBM 1742 " listed in the DsmSupportedDeviceList value?
If answers to #5 and #6 are both YES, is the storage SPC-3 compliant? Specifically, does it
support the ALUA semantics?
If answer to #3 is NO, try uninstalling the MPIO Optional Component (OC) and after rebooting,
perform step #3 (bypassing steps #1 and #2) and see if the devices show up under the adapters.
Using mpclaim.exe to configure MPIO on Windows Server 2008
With Windows Server 2008, MPIO can be configured from the command line tool MPCLAIM. This
capability is also available when using Windows Server 2008 "Server Core".
Installs MPIO OC and then ensures MSDSM claims passed in device.
Usage: mpclaim reboot_option install_switch device_switch device_hwid(s)
reboot_option Whether to automatically reboot or not
-r automatically reboot without prompting
-n suppress reboot request (CALLER IS EXPECTED TO REBOOT)
install_switch Whether to multipath or remove MPIO support
-i install MPIO OC and add multipath support for device
-u remove multipath support for device and uninstall MPIO
OC if no remaning devices are multipath'd
device_switch Whether to apply above options to all devices or passed in devices
-d following parameters indicate hardware ids of devices
-a work on all applicable devices
device_hwid HardwareIDs of Devices to be MPIO'd, as strings of vendor8product16,
delimited by a space (Note: Use empty string with '-a' option)
Add MPIO support for FC device(s):
mpclaim.exe -r -i -d <device#1_hardwareID> <device#2_hardwareID>
NOTE: if the MPIO optional component is not installed, the tool will install it first.
eg. To add MPIO support for a device with Vendor=ABC and Product=WXYZ
mpclaim -r -i -d "ABC WXYZ "
(notice that the vendor string length is made 8 chars and the product string length is made 16 chars
and both fields are padded with spaces as needed.)
For example, to add MPIO support for devices with Vendor==ABC, Product==WXYZ and
Vendor==DE, Product==JKLMN
mpclaim -r -i -d "ABC WXYZ " "DE JKLMN "
Add MPIO support for iSCSI devices:
mpclaim -r -i -d "MSFT2005iSCSIBusType_0x9"
Add MPIO support for all devices that are multipathed:
mpclaim.exe -r -i -a ""
NOTE: If the MPIO optional component is not installed, the tool will install it first. Also, the tool will
go through all devices seen by the system, determine if there are multiple paths to the
device, and if yes, add MPIO support for it. If any iSCSI disk device is found, MPIO support
will be added for all iSCSI disk devices.
Remove MPIO support for FC device(s):
mpclaim.exe -r -u -d <device#1_hardwareID> <device#2_hardwareID>
NOTE: if the MPIO optional component is installed, the tool will also uninstall it.
eg. To remove MPIO support for a device with Vendor==ABC and Product==WXYZ
mpclaim -r -u -d "ABC WXYZ "
(notice that the vendor string length is made 8 chars and the product string length is made 16
chars)
eg. To remove MPIO support for devices with Vendor==ABC, Product==WXYZ and Vendor==DE,
Prouct==JKLMN
mpclaim -r -u -d "ABC WXYZ " "DE JKLMN "
Remove MPIO support for iSCSI devices:
mpclaim.exe -r -u -d "MSFT2005iSCSIBusType_0x9"
Remove MPIO support for all devices on the system:
mpclaim.exe -r -u -a ""
NOTE: if the MPIO optional component is installed, the tool will also uninstall it. Also, the tool will
remove MPIO support for all devices on the system, even if multiple paths do NOT exist to the
array. Use caution when removing MPIO optional component from the system.
Installation of MPIO on Server Core installations of Windows
Since a Server Core installation of Windows Server 2008 does not contain a Graphical User
Interface (GUI), installation of the MPIO feature is done from the CMD prompt.
Note: the commands listed in this section are only available on server core versions of Windows
Server 2008.
In order to list the Roles and Features currently installed, type "oclist" (without quotes) at the CMD
prompt. This will list all of the roles and features and their current installation state.
Example oclist output showing the MPIO feature installed:
The MPIO feature may then be installed or removed using the ocsetup.exe tool.
Note: When adding and removing roles and features using the ocsetup tool, the name of the
component is case sensitive based on the name listed in the oclist tool.
To install MPIO on server core:
1. At the command prompt, type "start ocsetup MultipathIo" (without quotes).
1. At the command prompt type "start ocsetup MultipathIo /uninstall" (without quotes).
After the uninstall is complete, the following message will be displayed:
2. To restart the system and enable the change, click Yes, otherwise click No to postpone the
restart until later.
Access the MPIO control panel on server core:
1. To access the MPIO control panel on a server core installation, type "mpiocpl.exe" (without
quotes) at the CMD prompt, and press ENTER.
MPCLAIM.exe may also be used on server core to configure MPIO support after the feature is
installed. For more information on MPCLAIM usage see the section on MPCLAIM earlier in this
Appendix A – Script Example : Query the MPIO Policy for a device
Please note, the use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
The following script example shows how to query the current load balancing policy for MPIO
Once it successfully runs, it will print out integer values. i.e.) 1, 2, 3, 4, 5, 6, and 7
These values represent the following MPIO policies:
1 "Fail Over Only"
2 "Round Robin",
3 "Round Robin with Subset"
4 "Dynamic Least Queue Depth"
5 "Weighted Paths"
NOTE: The script uses DSM_QueryLBPolicy_V2 class to query the current LB policy
setting. The class works on W2K8+ , but it won't work on W2K3. For W2K3,
DSM_QueryLBPolicy has to be used instead.
Const wbemFlagReturnImmediately = &h10
Const wbemFlagForwardOnly = &h20
strComputer = "."
WScript.Echo
Set objWMIService = GetObject("winmgmts:\\" & strComputer &
"\root\WMI")
Set colItems = objWMIService.ExecQuery("SELECT * FROM
DSM_QueryLBPolicy_V2", "WQL", _
wbemFlagReturnImmediately +
wbemFlagForwardOnly)
For Each objItem In colItems
WScript.Echo "Active: " & objItem.Active
WScript.Echo "InstanceName: " & objItem.InstanceName
WScript.Echo "LoadBalancePolicy: " &
objItem.LoadBalancePolicy.LoadBalancePolicy
Appendix B – MPIO & DSM Configuration and best practices
When configuring a disk device to be managed by MPIO for multipath access, the hardware ID for
the disk device is required to be present in two different locations in registry in order to be claimed
by MPIO and the DSM managing connection to the device. These two locations are:
HKLM\System\CurrentControlSet\Control\MPDEV\MPIOSupportedDeviceList
HKLM\System\CurrentControlSet\Services\<DSMNAME>\Parameters\DsmSupportedDeviceList
Note: For both registry keys listed in this section, they are REG_MULTI_SZ data values, so if a
number of devices are configured, it may be necessary to actually open this key with REGEDIT in
order to view all of the hardware ID's.
By default, the only value listed in this key will be "Vendor 8Product 16" (without quotes) will be
listed for a hardware ID associated with MPIO. This entry is intended as an example only to show
the correct hardware ID format which is made up of an 8 byte vendor ID followed by a 16 byte
product ID.
If the device will be associated with the Microsoft DSM (MSDSM), then the <DSM NAME> will be
MSDSM. If the device connection will be handled by a vendor provided DSM, then the name of this
key will be dependent on the service name associated with the DSM in the
HKLM\System\CurrentControlSet\Services registry hive.
It is strongly recommended that the hardware ID for a specific disk device should be configured
such that it is only associated with one DSM in the services key. This will help ensure that the
device is only available to be claimed by the desired DSM, and will help avoid a situation where a
disk is not claimed by the desired DSM, when multiple DSM's have the ability to support a given
device. This process may also be used to determine which DSM a disk drive could be associated
with for troubleshooting purposes.
Warning: Removing hardware ID's from DSM's that are not required should be performed by
editing the registry keys directly, as removing a device from the MPIO GUI will result in the
hardware ID being removed in both registry locations above and prevent the device from being
claimed by the desired DSM.
When a hardware ID is listed in both locations detailed above, it does not indicate that the hardware
ID will be actually claimed by the given DSM, it is just an indication that it would be possible for the
devices to be claimed by the DSM. The DSM that is actually used for a given device is randomly
selected from all DSM's that the hardware ID is registered with.
Note: If the hardware ID is listed with the MSDSM, that DSM will be selected only if no other DSM's
claim the device.
The DSMSupportedDeviceList key contains the hardware ID's of all devices that are capable of
being associated with the selected DSM.
To search for hardware ID's registered with more than one DSM:
In order to determine which DSM's a hardware ID are associated with, perform the
following steps.
1. Using Regedit, open the following registry key:
2. The list of current hardware ID's will be displayed such as the example from regedit.exe
3. Select one line from the Value Data filed, and Right-Click and choose copy.
Such as "Vendor 8Product 16".
4. From the Edit menu in Regedit.exe, choose Find.
5. In the Find What box, right-click, and choose Paste.
6. Click the Find Next button. This will jump to the first DSM that this hardware ID is
associated with. Make a note of the registry path listed at the bottom of the Registry Editor
window such as the path to the MSDSM entry listed below.
HKLM\System\CurrentControlSet\Services\msdsm\Parameters
In order to check for registration with other DSM's, repeat step 6 until the Registry Editor
finishes searching the registry:
7. In order to disassociate the hardware ID with a DSM to prevent it from being claimed by a
particular DSM, remove the hardware ID from only the entry under the DSM's entry in the
Services registry hive leaving only the hardware ID's that you wish to have claimed by the
DSM.
A reboot is required after this step for the changes to take effect.
To add a hardware ID to be used with MPIO:
1. Open the MPIO control panel.
On the Mpio'd devices tab, click the Add button.
2. In the Add MPIO Support dialog box, paste in the hardware ID for the device to be
managed by MPIO and then click OK.
For information on determining the hardware ID of a device to be used with MPIO, see Appendix
C : Determining the hardware ID to be used with MPIO.
After the device is claimed by MPIO, the device originally shown in Device Manager will be hidden,
and a pseudo-LUN device will be shown in device manager.
For example, the single path disk device listed in device manager which is named "emBoot
sanFly SCSI Disk device" will become a hidden device, and will be replaced with a new
device named "emBoot sanFly Multi-Path Disk Device".
The exact name will depend on a number of items, such as the type of device and the DSM being
The original disk device is still viewable in Device Manager by choosing "Show Hidden Devices"
from the Action menu.
Appendix C – Determining the Hardware ID to be used with MPIO
In order to add the hardware ID for a device to MPIO to allow the device to be managed by MPIO, it
is first necessary to obtain the hardware ID from the device, and then format the hardware ID
differently so that it can be recognized by MPIO.
To determine the hardware ID for a disk device to use with MPIO, perform the following steps:
Note: These steps assume that the device is already configured and presented to the system.
1. Click Start, type "Devmgmt.msc" (without quotes), and press ENTER.
2. In Device manager, click the plus symbol next to Disk Drives to expand the category.
3. Right-Click the desired disk device, and choose properties.
4. Click the Details Tab.
5. In the Property drop down list, select Hardware ID.
6. A list such as the example below will be displayed:
7. The hardware ID is in the format of TYPE\Vendor_Product/model. The vendor field is 8
bytes, followed by a 16 byte field to describe the product type or model, such as:
"SCSI\DiskemBoot__sanFly__________" (Not including quotes).
Right-Click the hardware ID, and choose Copy.
8. Open Notepad, and paste this string into Notepad.
9. Next we must convert the string to the format that is used with MPIO. The first step will be
to remove the device type (In this case "SCSI\" (without quotes) from the string. This would leave
the resulting string:
"emBoot__sanFly__________" (Not including quotes).
10. Next, we must convert the number of underline characters to an equal number of spaces.
In this example, there are 2 underlines in the middle, and 10 trailing underline characters. The
resulting string is:
"emBoot sanFly " (Not including quotes).
11. The resulting string listed in step 10 above is the value that will be listed in the MPDEV and
DSM registry keys that are detailed in Appendix B in order to allow the device to be claimed by
MPIO.
Appendix D – Enabling software tracing for MPIO
This section describes how to enable software trace logging for troubleshooting MPIO Issues.
Note: Software trace logs are binary files that will typically only be used by Microsoft Product
Support in the course of troubleshooting an issue, and are not directly viewable.
Creating GUID file to enable tracing
First a <GUID File> needs to be created using notepad.exe and contain the GUID of the provider
that corresponds to the driver that we want trace for. For this example we will use MPIOGUID.CTL
as the file name.
The file will contain the first line if we want it for MPIO and the second line if we want it for MSDSM.
{8E9AC05F-13FD-4507-85CD-B47ADC105FF6} 0x0000FFFF 0xF
{DEDADFF5-F99F-4600-B8C9-2D4D9B806B5B} 0x0000FFFF 0xF
The format of these files is as follows:
<GUID of provider to trace> <Trace Flags> <Trace Level>
Note: The Trace Flag and Trace Level values will typically be specified by product support
depending on the type of troubleshooting being performed.
Start Trace
To start tracing, do the following from a CMD Prompt:
logman.exe create trace <Name> -ets -nb 16 256 -bs 64 -o <LogFile> -pf <GUID File>
logman.exe is present in %windir%\system32 directory. The above command starts a trace
session. The name <Name> is assigned to that session. The trace level is controlled by the value of
the flag in the GUID File. <Guid File> contains the trace GUID and trace flag. The trace messages
are written to <Log File>.
For example, to start a trace session by named MPIOTrace and log file named MPIOTrace.Log, do
logman.exe create trace MPIOTrace -ets -nb 16 256 -bs 64 -o MPIOTRACE.log -pf
MPIOGUID.CTL
Stop Tracing
To stop tracing do the following from CMD prompt:
logman.exe stop <Name> -ets
For example, to stop the trace session with name MPIOTrace, do
logman stop MPIOTrace -ets
The log file is a binary file. If you are troubleshooting an MPIO issue via Microsoft Product support
services, please send the log file to them to assist in analyzing the failure.
Query Trace Status
To verify that tracing is running properly, do the following from a CMD prompt.
logman.exe query -ets
To return extended information about the tracing status, do the following from the CMD prompt:
logman query MPIOTrace -ets
Appendix E - MPIO timers
1. PathVerifyEnabled: This flag enables path verification by MPIO on all paths every N
seconds (where N depends on the value set in
PathVerificationPeriod).
Type is boolean and must be filled with either 0 (disbale) or 1
(enable). By default, it is disabled.
2. PathVerificationPeriod: This setting is used to indicate the periodicity (in seconds) with which
MPIO has been requested to perform path verification. This field is
only honored if PathVerifyEnabled is TRUE.
This timer is specified in seconds. The default is 30 seconds. The
max allowed is MAXULONG.
3. PDORemovePeriod: This setting controls the amount of time (in seconds) that the
multipath pseudo-LUN will continue to remain in system memory,
even after losing all paths to the device.
4. RetryCount: This setting specifies the number of times a failed IO if the DSM
determines that a failing request must be retried. This is invoked when
DsmInterpretError() returns Retry = TRUE.
The default setting is 3.
5. RetryInterval: This setting specifies the interval of time (in seconds) after which a
failed request is retried (after the DSM has decided so, and assuming
that the IO has been retried lesser number of times than RetryCount).
This value is specified in seconds. The default is 1 second
Appendix F – Acronyms:
ALUA Asymmetric Logical Unit Access
DDK Driver Development Kit
DSM Device Specific Module
FC Fibre Channel
FS File System
FT Fault Tolerant
GUI Graphical User Interface
HBA Host Bus Adapters
I/O Input / Output
IHV Independent Hardware Vendor
IIS Internet Information Server
iSCSI Internet SCSI
ISV Independent Software Vendor
IT Information Technology
LUN Logical Unit Number
MPIO Multi-path I/O
MSCS Microsoft Cluster
M Microsoft DSM
NIC Network Interface Card
NLB Network Load Balancing
OC Optional Component
NTFS New Technology File System
PDO Physical Device Object
PnP Plug and Play
Redundant Array of
RAID Independent Disks
SAN Storage Area Network
SAS Serial Attached SCSI
Small Computer System
SCSI Interface
SPC-3 SCSI Primary Commands – 3
USB Universal Serial Bus
Windows Management
WMI Interface
WSFC Windows Failover Clustering
The Microsoft MPIO framework provides hardware and software vendors with a means of creating
Microsoft MPIO solutions that work effectively with the Windows Server operating system to provide
organizations with reliable multiple path support on Windows Server 2008 and Windows
Server 2003, The Microsoft MPIO solution provides support for Fibre Channel, parallel SCSI, Serial
Attached SCSI and iSCSI storage and also ensures that MPIO based storage solutions from
different storage partners can coexist on the same Windows Server host.
Information about the Windows Hardware Quality Labs is available at
http://www.microsoft.com/whdc/winlogo/default.mspx
Products designed for use with Windows are listed at
http://www.microsoft.com/whdc/hcl/default.mspx
Information about Windows Management Instrumentation (WMI) is available at
http://msdn2.microsoft.com/en-us/library/aa394582(VS.85).aspx.
More information on the Microsoft iSCSI Software initiator is listed at
http://www.microsoft.com/iSCSI
More information on the Microsoft Storport driver is available at:
www.microsoft.com/storport
Load Balancing (Computing)
Documents Similar To mpio
Oier Badiolairiarte
collims
Claudio Andrés Salas Vásquez
abhi_icis
nkj_nbp
sixstringguy
ซิสทูยู ออนไลน์
mumarbsc7244
sinistral7196
Abey Francis
manojmanoj123
Ben Lin
Seu Ze Ninguem
Kang JadiJaya Otodidak
Jose Luis Pittau
Dhanish Vijayan
dSolarian
Tinchu Shrivastava
MCB 51-2 Quick Start Guide 1
GAUTI2212
Chap 4Lesson05Device Driver
reneeshcz
elipsemodsimmanual_enu
Anderson Santos
pso2_dxdiag
AmayaKuzunoha
juampic
NCS 4206 HW Install
Antivirus and Content Security Clustering Solution
Neeraj Kumar
Xagyl FW5125 User Manual
Almir Germano
fusd
fmcc
Prepking 920-249 Exam Questions
scovatta9979
Popular in Device Driver
CONFIGURACION DE ARIES PC.doc
Ambar Anzola
IntelliTrac U Series User Guide v1 4 (2)
oundilahmed
Asio Driver User Manual
Manuel Carrascosa Molina
11-ZXPOS CNT Operation Guide
Maxime Netstat Tchapo Tanté
Rapidose User Manual
Danielec1
PPremium UserGuide
EasyPLC User Manual.pdf
Javier Abonza
ENT GD
anuragsharmatech
Manual 000038726
Младен Башић
UsbMon Manual
jcsanchezrb
FS 8700 48 Fike Cheetah
Eric Dunn
STM32F10xxx SPI Application Examples
smb6111
Fatal1ty FM2A88X+ Killer Series
Alexandru Relea
NI-USB6009
williamII
Linux Important Material
manojmuthyala
ijsea040206
ijsea
Acpi Linux
ido2003
manual user
Homar Mur
LabVIEW Programmers Reference
magicecstatic
Usb Modem Not Working Windows 8_8
Satya Prakash Gupta
Uber Partners and Drivers 2013/Page14 missing
SuperAdventureDoug
Jose Perez Guzman
Soft Key Solutions - HASP4 HASP HL Hardlock Dongle Emulator for Aladdin Hardware Key
Zulkarnain Nasrullah
Zebra OPOS ZPL & CPCL Programmers Guide
Bitenka
Unit3Fall08
Ulin Nuha
DPR-1061_A1_Manual_1.00(WW)
Luiz Roberto Servulo
5 Axis CNC Breakout Board
zeca2zeca
ju.pdf
Williams Medina
Audio 8 DJ Manual English
siegfried_roos


text:
Timberwolves Week 6: We need to talk about Kevin
Minnesota won twice in two games in week six, but the real action was off the floor, where Kevin Love aired his frustration with the franchise at a curious time.
By Jon Marthaler Dec 13, 2012, 9:01am CST
Share All sharing options for: Timberwolves Week 6: We need to talk about Kevin
Greg Smith-USA TODAY Sports
The Timberwolves' season thus far has been defined by uncontrollable frustrations. More than half the team has already missed significant time with injuries, and Ricky Rubio has yet to even see the floor. Injuries are uncontrollable, and the Wolves know better than most the dent that this can cause in a team's fortunes.
At the moment, though, things should be looking up. Rubio's back at practice, and could play in Saturday's game against Dallas. Andrei Kirilenko returned from back spasms to key the Wolves' win over Denver. Nikola Pekovic's injured foot appeared to be fine in that same win, as he scored 22 points and grabbed 17 rebounds. J.J. Barea looks to be mostly recovered from his sprained foot.
Things should be looking up. The Wolves won twice in week six - drubbing Cleveland at home, then outlasting the whirling dervishes from Denver, one of the teams they'll likely battle for a Western playoff spot. And though Wednesday's game began a stretch of six games in nine days, fans should be looking forward to next week, when Minnesota tests itself against both Miami and Oklahoma City.
Instead, the focus was off the floor, as Kevin Love decided that now would be a good time to re-air every grudge he holds against the Timberwolves' front office. The interview, with Yahoo! Sports columnist Adrian Wojnarowski, caused a furor in the Twin Cities, as fans re-assessed the player who had become perhaps the most popular athlete in Minnesota.
We need to talk about Kevin.
1. Most importantly, there's no point in worrying about what you'd do with the money if you won the lottery. Love is unhappy with his contract, but he's still under contract through 2015. For a Timberwolves team that hasn't made the playoffs since 2004, worrying about the 2015-2016 roster is putting the cart light-years in front of the horse. Let the Timberwolves have some success, maybe even make a playoff run, before we start worrying about whether management can hold the team together.
2. Love may be one of those guys that fuels himself based on the perceived slights of others. Though no one compares to Michael Jordan, it's instructive to remember that he was the same way, always feeling there was a score to settle, real or imagined, in everything he did. Love has names to go with his slights - owner Glen Taylor and president of basketball operations David Kahn - but he's already been using them to turn himself into one of the best players in the league. If he needs to use some imagined conflict to make him even better, then that's a situation that even Kahn and Taylor might accept.
3. Though it seems like Love has been around forever, it's probably instructive to remember that he's just 24 years old, and that he's still growing into the role of team leader / face of the franchise. It's not necessarily a role that comes naturally. Kevin Garnett seemed to struggle with it throughout his time in Minnesota, even after the team made him the highest-paid player in basketball. To change sports and cross a Minneapolis street, Twins catcher Joe Mauer still seems unable to assume that role, even after nine professional seasons. Love spoke Wednesday about learning that he needed to keep his criticisms in-house; if this points him in the correct direction, in terms of leading the team, a small good thing may be rescued from the ashes of a large bad thing.
4. That said: how was there not a part of Love's brain that told him, "You know, I probably shouldn't give a national writer a ton of negative quotes in the middle of the season?"
5. Love didn't say anything untrue about Kahn, nor did he say anything that most of us haven't said a hundred times already. Love said, "Is there really any kind of plan here?" Anyone who's watched Kahn's spastic, panicky method of building a franchise knows that the answer is no. If Love had really wanted to hurt Kahn's feelings, he could have just said, "Jonny Flynn is playing in Australia."
6. For the moment, the "Love affair" that Minnesota fans had with #42 is over. He got heckled from the stands on Wednesday, mostly a function of the article but also a function of a 3-17 performance from the floor. But if he scores 35 points against Miami and Oklahoma City next week and the Wolves win both games, I guarantee that the entire city will forget that he ever said anything about anyone.
This may well turn out to be the key week of the season for the Wolves. They play Friday, Saturday, Monday, and Tuesday, with only Saturday's game coming at home. A successful week, and Love's outburst will be forgotten. A disastrous week, and the history of the Wolves' 2012-13 season will begin to be written - one in which Love's dissension scuttled an otherwise promising, potential-filled year.
Health update: Rubio will almost certainly return at home, and if he does not play Saturday against Dallas, it's a virtual lock that he'll play the following Thursday against the Thunder... Josh Howard missed Wednesday's game due to illness - possibly the same bug that Love had to overcome last week... Malcolm Lee hyperextended his knee Wednesday, missing the second half of the game, and is day-to-day... Brandon Roy has begun shooting on his own following his mid-November arthroscopic knee surgery, but is not yet close to returning to practice.

redpajama_set_name: RedPajamaCommonCrawl


text:
Biomin F: prevention of sensitivity following whitening treatment
By Moira Crawford on 29 May 2019
Teeth whitening procedures can cause dentine sensitivity in at least 50% of patients. Use of Biomin F toothpaste can reduce any existing sensitivity ahead of treatment, and prevent it from developing during and after the procedure. Moira Crawford reports.
Tooth whitening has become one of the most popular and widely carried out cosmetic dental procedures, and is a valuable source of income for the dental practice. Regulation of the whitening industry and refinement of the bleaching products have made this a very safe treatment, but according to the British Dental Bleaching Society (BDBS), at least 50% of patients are likely to develop sensitivity following the treatment. This can range from a mild awareness of the teeth to shooting pains, sometimes so severe that the patient cannot continue treatment. The BDBS recommends the use of desensitising products in order to manage the problem.
By law, tooth whitening may only be carried out by a qualified dental professional, and regulations limiting the concentration of the bleaching agents have reduced the incidence of post-whitening sensitivity. However, the action of hydrogen peroxide or carbamide peroxide, the most common bleaching agents, passing through the tooth enamel and into the dentine to lighten the colour, can still cause sensitivity in certain patients. Some may already suffer from sensitivity, and it is essential that this is brought under control before treatment is started. Ideally too, patients should use a desensitising toothpaste ahead of commencing whitening treatment to prevent sensitivity developing in the first place.
A number of toothpastes aimed at the management of sensitivity are available for patients to purchase, but Biomin F, an innovative new toothpaste that takes a different approach to oral hygiene, offers a highly effective alternative to previous generations of sensitivity products, not only managing sensitivity but also preventing it from developing.
Figure 1: Before application of Biomin F
Biomin F
Bioactive glass technology was originally developed for use in bone grafting, but was found to have a positive effect on remineralising tooth enamel by the formation of hydroxyapatite. Biomin F is based on a new generation of bioactive glass, specifically designed for dental use, and incorporating fluoride and a greater level of phosphate to form fluorapatite, the fluoride analogue of the apatite in natural tooth enamel.
Following brushing with the product, it adheres to the tooth surface, where it dissolves gradually over up to 12 hours, acting as a slow release vehicle for a carefully balanced combination of calcium, fluoride and phosphate ions. These ions work in concert with the saliva in the mouth to form fluorapatite, which is more stable and resistant to acid attack than hydroxyapatite.
Research at Queen Mary University, London, where the product has been developed, has shown it to be more effective than other sensitivity treatments, both at remineralising enamel and reducing and preventing sensitivity.
The fine particles of Biomin F adhere not only to the surface of the tooth, but are also small enough to enter the exposed dentine tubules, occluding them and depositing fluorapatite, so preventing fluid movement (hydraulic conductance) which is the cause of sensitivity. It is thought that fluorapatite is formed preferentially on the apatite-rich walls of the dentine tubules, re-mineralising them and both halting and preventing sensitivity from arising. The whitening treatment leaves the tubules exposed and susceptible to sensitivity, so if there is any predisposition towards sensitivity arising, this needs to be treated before the whitening programme commences, and to continue during and after treatment to prevent it occurring.
Figure 2: After application of Biomin F
Dentists and hygienists are finding that using Biomin F is extremely effective in combating the sensitivity caused by whitening treatments. Sam Davidson, a hygienist working in several practices across the South East of England, found herself needing to trial it. She had had whitening treatment which caused her to experience sensitivity when breathing in cold air. The sensitivity was so intense that she had had to cease the treatment, but after 14 days of using BioMin F she was able to continue. 'I now routinely recommend it for patients both before starting whitening and during or following the treatment,' she said.
Dr Don Gibson of Yeovil was particularly attracted by the science behind Biomin F, especially the slow release principle of laying down the apatite over several hours. He also liked the fact that Biomin F had been developed in the labs of a dental hospital, by dentists and scientists rather than by a big multinational corporation. He admitted that he was always interested in trying out new technology but soon realised that Biomin F was extremely effective. The improvement he saw in patients suffering from sensitivity was such that he now recommends it widely and routinely offers it when he is about to embark on a whitening programme. 'It's now standard procedure in the practice,' he said.
Dr Mark Maharaj in Swindon agreed. 'I recommend it pre- and post-whitening,' he said. 'Patients have seen such positive results that they continue to use it and come back for more.'
Californian hygienist and continuing education speaker Theresa McCarter, sees a great deal of sensitivity caused by whitening. In a place where image is so important, there is a lot of over-use of whitening products, including home kits, and as a result, problems with sensitivity are common. She has recommended Biomin with great success in several cases. One patient in particular had overused whitening products to the extent that her teeth were almost translucent. 'After five months of using Biomin there is a visible improvement in the density of her teeth,' explained Theresa. 'We recommend only in-office treatments, and provide Biomin alongside it to prevent sensitivity arising.'
At Mullingar Dental Centre in Ireland, Dr Anne O'Donnell and hygienist Donna Paton are extremely impressed by the improvement not only in their patients' sensitivity problems but also in preventing white spot lesions in orthodontic patients and for perio patients. They now regularly give out a sample of Biomin F when carrying out scaling or whitening procedures. 'The effect is very convincing – 'no other toothpaste does what Biomin does, said Dr O'Donnell. 'It strengthens enamel in a different way, helps with sensitivity, and is a game changer.'
Tooth whitening is such a popular treatment, having such a positive effect on patients' self esteem, that it is only going become more widely carried out. It does, however, carry a risk of causing sensitivity which can be lead to patient non-compliance for further home bleaching programmes, and hence reduce the effectiveness of the procedure and patient satisfaction. Now offering patients the option to brush with Biomin F before and during treatment offers a simple and safe way to bring comfort to the tooth whitening process and increase the frequency with which patients will demand the procedure.
Figure 3: After acid challenge tubules remain occluded
*For patients who do not wish to use a product containing fluoride, Biomin C is available, containing phosphate and calcium, and which has been shown to be second only to Biomin F in terms of re-mineralising tooth enamel and preventing sensitivity.
Moira Crawford
Author at Dentistry.co.uk
Moira Crawford is a freelance health writer and editor.