https://msdn.microsoft.com/ko-kr/library/windows/desktop/bb986750(v=vs.85).aspx
[Beginning with Windows 8 and Windows Server 2012, the Virtual Disk Service COM interface is superseded by the Windows Storage Management API.]
------------------------------------------------------------------------------------------------------------
https://msdn.microsoft.com/ko-kr/library/windows/desktop/aa381442(v=vs.85).aspx
About VDS
[Beginning with Windows 8 and Windows Server 2012, the Virtual Disk Service COM interface is superseded by the Windows Storage Management API.]
Virtual Disk Service is a Microsoft Windows service that performs query and configuration operations at the request of end users, scripts, and applications. The service extends the existing storage capabilities of Windows Server operating systems in the following ways:
- Provides an API to the existing volume and disk management features in Windows.
- Unifies volume management and hardware Redundant Array of Independent Disks (RAID) management under a single API.
VDS does not perform the following storage-management activities:
- Hardware subsystem management, such as temperature monitoring or the monitoring of performance statistics for disk arrays.
- Storage Area Network (SAN) fabric management, such as Host-Based Adapter (HBA) zoning and security.
The sections that follow describe the architecture of VDS, the role of VDS providers, and the API.
Service Architecture
VDS defines three interfaces: a single interface between the application layer and the service, and two interfaces between the service and provider programs in the data layer. The following illustration shows the application-to-service boundary and the service-to-provider boundary.
N-tier architecture enables VDS to coordinate with the file-system functions, synchronize provider activities, and arbitrate between applications. Being between the application and provider, VDS presents uniform functionality to applications even though some the underlying providers might lack such uniformity.
The service implements common functionality: formatting volumes, adding and removing drive letters or mounted folders, as well as managing unallocated disks—disks having no partition information. VDS also returns event notifications to registered applications. For details, see VDS Notifications.
Role of Providers
VDS defines two provider interfaces, one for a software provider and one for a hardware provider. Each provider implements a different portion of the API defined by VDS:
- A software provider is a host-based program that is supported by a kernel-mode driver in the storage I/O stack. The provider-kernel runtime interacts with the Mount Manager at boot time or the Plug and Play (PnP) Manager at discovery time to claim each disk. Software providers operate on volumes, disks, and disk partitions.
VDS includes two provider types. The basic software provider manages basic disks and offers no fault-tolerant binding. The dynamic software provider manages dynamic disks and offers fault management where applicable. Software-provider behavior is consistent with the behavior of basic and dynamic disks on the host. For example, if the operating system of a given host supports fault-tolerant dynamic disks, VDS also supports this behavior on the host.
- A hardware provider implements the methods that are used to manage a storage subsystem—a hardware disk array or adapter card that enables the creation of logical disks configured to enhance performance, data availability, or data recovery. Many major RAID cabinet manufacturers have produced a hardware provider that is designed for use with VDS. Service consumers must obtain a hardware provider and associated hardware from the manufacturer.
The capabilities of a hardware provider depend on the capabilities of the underlying hardware. Consequently, the degree to which each manufacturer implements the API can vary. For example, manufacturers can include additional methods to optimize configurations, monitor and dynamically tune performance, automate fault management, or provide other beneficial functionality.
Hardware providers offer several configuration options that are not available to the software providers. Most notable is the automagic configuration model, which presents an attribute-based view of storage to each application. Binding hints, such as "mostly reads" or "fast crash recovery required" replace the complexity of binding physical storage into virtual storage. Each hardware provider performs extent mapping, space allocation, and binding-type selection based on the hints that are submitted by an application. For the complete hardware provider description, including the configuration options, see the documentation that is supplied by the subsystem manufacturer.
Application Programming Interface
Applications can invoke VDS methods to query and configure host-based disks, RAID storage, or both. For an overview of the API, see the VDS Object Model.
Typical applications for VDS solve configuration management and monitoring problems, and range from dedicated storage-management systems to back-office applications seeking better control over configuration or fault management. The following applications use VDS today:
- The Disk Management snap-in configures and manages disks controlled by a host computer. System administrators and end users can query and configure local (or remote) disks and volumes with this user interface (UI) tool.
- Diskpart.exe is a command-line utility that configures and manages disks, volumes, and partitions.
- Diskraid.exe is a command-line utility that configures and manages hardware RAID subsystems. This utility can interact with any storage hardware that is accompanied by a VDS hardware provider.
Related topics
-------------------------------------------------------------------------------------------------------------------------------------------
https://msdn.microsoft.com/ko-kr/library/windows/desktop/aa383400(v=vs.85).aspx
VDS Notifications
[Beginning with Windows 8 and Windows Server 2012, the Virtual Disk Service COM interface is superseded by the Windows Storage Management API.]
A provider can send an event notification to VDS, and VDS can in turn forward the notification to applications. The notification model that is used by VDS resembles the connection-point model that is used by COM objects.
VDS generates service notifications for events such as a drive letter assignment or the arrival of an unallocated disk. once VDS allocates a disk to a provider, the provider is responsible for generating the associated notifications. The illustration that follows shows the interfaces and methods used in the VDS notification model.
To receive notifications, VDS registers its IVdsAdviseSink interface with the provider object by calling the IVdsProviderPrivate::OnLoad method and passing a pointer to the interface. When a notification event occurs, such as the arrival of a new volume or drive, the provider passes the appropriate notification structure to VDS as an IVdsAdviseSink::OnNotify method parameter.
The process is similar between an application and VDS. Specifically, to receive notifications, an application registers its IVdsAdviseSink interface with VDS by calling the IVdsService::Advise method and passing a pointer to the interface. When VDS receives a notification from a provider, it passes the appropriate notification structure to registered applications as an IVdsAdviseSink::OnNotify method parameter.
The table that follows lists the provider-generated notifications by object type.
| Object | Notification | Value | Link to event description |
|---|---|---|---|
| Pack | VDS_NF_PACK_ARRIVE | 1 | VDS_PACK_NOTIFICATION |
| Pack | VDS_NF_PACK_DEPART | 2 | VDS_PACK_NOTIFICATION |
| Pack | VDS_NF_PACK_MODIFY | 3 | VDS_PACK_NOTIFICATION |
| Volume | VDS_NF_VOLUME_ARRIVE | 4 | VDS_VOLUME_NOTIFICATION |
| Volume | VDS_NF_VOLUME_DEPART | 5 | VDS_VOLUME_NOTIFICATION |
| Volume | VDS_NF_VOLUME_MODIFY | 6 | VDS_VOLUME_NOTIFICATION |
| Volume | VDS_NF_VOLUME_REBUILDING_PROGRESS | 7 | VDS_VOLUME_NOTIFICATION |
| Disk | VDS_NF_DISK_ARRIVE | 8 | VDS_DISK_NOTIFICATION |
| Disk | VDS_NF_DISK_DEPART | 9 | VDS_DISK_NOTIFICATION |
| Disk | VDS_NF_DISK_MODIFY | 10 | VDS_DISK_NOTIFICATION |
| Partition | VDS_NF_PARTITION_ARRIVE | 11 | VDS_PARTITION_NOTIFICATION |
| Partition | VDS_NF_PARTITION_DEPART | 12 | VDS_PARTITION_NOTIFICATION |
| Partition | VDS_NF_PARTITION_MODIFY | 13 | VDS_PARTITION_NOTIFICATION |
| Subsystem | VDS_NF_SUB_SYSTEM_ARRIVE | 101 | VDS_SUB_SYSTEM_NOTIFICATION |
| Subsystem | VDS_NF_SUB_SYSTEM_DEPART | 102 | VDS_SUB_SYSTEM_NOTIFICATION |
| Subsystem | VDS_NF_SUB_SYSTEM_MODIFY | 151 | VDS_SUB_SYSTEM_NOTIFICATION |
| Controller | VDS_NF_CONTROLLER_ARRIVE | 103 | VDS_CONTROLLER_NOTIFICATION |
| Controller | VDS_NF_CONTROLLER_DEPART | 104 | VDS_CONTROLLER_NOTIFICATION |
| Controller | VDS_NF_CONTROLLER_MODIFY | 350 | VDS_CONTROLLER_NOTIFICATION |
| Controller | VDS_NF_CONTROLLER_REMOVED | 351 | VDS_CONTROLLER_NOTIFICATION |
| Port | VDS_NF_PORT_MODIFY | 352 | VDS_PORT_NOTIFICATION |
| Port | VDS_NF_PORT_REMOVED | 353 | VDS_PORT_NOTIFICATION |
| Drive | VDS_NF_DRIVE_ARRIVE | 105 | VDS_DRIVE_NOTIFICATION |
| Drive | VDS_NF_DRIVE_DEPART | 106 | VDS_DRIVE_NOTIFICATION |
| Drive | VDS_NF_DRIVE_MODIFY | 107 | VDS_DRIVE_NOTIFICATION |
| Drive | VDS_NF_DRIVE_REMOVED | 354 | VDS_DRIVE_NOTIFICATION |
| LUN | VDS_NF_LUN_ARRIVE | 108 | VDS_LUN_NOTIFICATION |
| LUN | VDS_NF_LUN_DEPART | 109 | VDS_LUN_NOTIFICATION |
| LUN | VDS_NF_LUN_MODIFY | 110 | VDS_LUN_NOTIFICATION |
VDS generates the remaining notifications. The following table lists service-based notification constants by category.
| Category | Notification | Value | Link to event description |
|---|---|---|---|
| Disk | VDS_NF_DISK_ARRIVE | 8 | VDS_DISK_NOTIFICATION |
| Disk | VDS_NF_DISK_DEPART | 9 | VDS_DISK_NOTIFICATION |
| Disk | VDS_NF_DISK_MODIFY | 10 | VDS_DISK_NOTIFICATION |
| Drive letter | VDS_NF_DRIVE_LETTER_FREE | 201 | VDS_DRIVE_LETTER_NOTIFICATION |
| Drive letter | VDS_NF_DRIVE_LETTER_ASSIGN | 202 | VDS_DRIVE_LETTER_NOTIFICATION |
| File system | VDS_NF_FILE_SYSTEM_MODIFY | 203 | VDS_FILE_SYSTEM_NOTIFICATION |
| File system | VDS_NF_FILE_SYSTEM_FORMAT_PROGRESS | 204 | VDS_FILE_SYSTEM_NOTIFICATION |
| Volume | VDS_NF_MOUNT_POINTS_CHANGE | 205 | VDS_MOUNT_POINT_NOTIFICATION |
Related topics
-------------------------------------------------------------------------------------------------------------------
https://technet.microsoft.com/en-us/library/cc778187(v=ws.10).aspx
What Is Virtual Disk Service?
Updated: March 28, 2003
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
In this section
- Common Virtual Disk Service Scenarios
- Technologies Related to Virtual Disk Service
- Virtual Disk Service Dependencies
- Related Information
For Windows 2000, each company that made storage devices (for example, hard disks, PCI RAID adapters, storage arrays) provided its own application for installing and managing that storage device. As a result, users had to run separate applications for each type of storage device they used on their computer system. This made managing the different types of storage devices difficult. To address this issue, Windows Server 2003 introduced Virtual Disk Service (VDS). VDS is a set of application programming interfaces (APIs) that provides a single interface for managing disks. VDS provides an end-to-end solution for managing storage hardware and disks, and for creating volumes on those disks.
VDS uses two sets of providers to manage your storage devices. The built-in VDS software providers enable you to manage disks and volumes at the operating system level. Hardware providers supplied by the hardware vendor enable you to manage hardware RAID arrays.
Each hardware vendor writes a VDS hardware provider that translates the general-purpose VDS APIs into specific instructions for their hardware. VDS simplifies storage management because storage applications no longer need to take into account the specific hardware being targeted. Because of VDS, you no longer need to use a different storage application to manage each different storage device. Instead, you can use one compatible storage application to manage any hardware that has a VDS hardware provider.
Windows Server 2003 components that work with VDS include the Disk Management snap-in, the DiskPart command-line tool, and the DiskRAID command-line tool (Diskraid.exe), which is available in the Windows Server 2003 Deployment Kit. DiskRAID requires at least one VDS provider supplied by a storage vendor.
Depending on the underlying disk subsystem, a disk can be a single physical hard disk (sometimes called a spindle), or it can be a group of hard disks bound together at the controller level and presented to the operating system as a single disk. This type of disk is often referred to as a virtual disk or logical unit number (LUN), and typically uses some form of hardware-based RAID to ensure data availability if one of the disks fails.
If your hardware vendor supplies a VDS hardware provider, you can use DiskRAID to manage individual physical disks, also called drives, in a LUN. The following example shows two DiskRAID printouts. The first printout shows information about the LUNs in a given disk subsystem. The second printout shows information about the physical disks that correspond to LUN 0.
How DiskRAID Displays LUNs in a Disk Subsystem
LUN ### Status Health Type Size Sub Dev ------- ---------- ------------ -------- -------- --- --- LUN 0 online Healthy Stripe 1064 GB 0 3 LUN 1 online Healthy Parity 200 GB 0 4
How DiskRAID Displays the Disks Associated With LUN 0
Drive ### Status Health Size Free Bus Slot Flags --------- ---------- ------------ -------- -------- --- ---- ----- Drive 0 online Healthy 66 GB 66 GB 0 5 Drive 1 online Healthy 66 GB 35 GB 0 0 Drive 2 online Healthy 66 GB 35 GB 1 0 Drive 3 online Healthy 66 GB 66 GB 1 11 Drive 4 online Healthy 66 GB 66 GB 0 7 Drive 5 online Healthy 66 GB 66 GB 0 8 Drive 6 online Healthy 66 GB 35 GB 1 3 Drive 7 online Healthy 66 GB 66 GB 1 7 Drive 8 online Healthy 66 GB 35 GB 0 2 Drive 9 online Healthy 66 GB 66 GB 1 9
Windows Server 2003 supplies VDS software providers for basic and dynamic disks and volumes so that you can use tools such as the Disk Management snap-in and DiskPart command-line tool to manage LUNs. However, the Disk Management snap-in and the DiskPart command-line tool display LUNs as disks, as shown in the following figure. Unlike DiskRAID, you cannot use these tools to view or manage the underlying physical disks in a LUN. However, using the Disk Management snap-in or DiskPart command-line tool, you can create partitions and volumes, convert disks to dynamic, and so forth. In the following figure, disk 2 (volume G:) and disk 3 (volume H:) are both on LUNs.
How Disk Management Displays LUNs As Disks
Common Virtual Disk Service Scenarios
VDS is commonly used in the following scenarios.
Managing LUNs on Hardware Storage Devices
VDS defines a set of features which provide a virtual view of any storage hardware. You can use the VDS APIs to write a storage management application that can manage any other storage hardware RAID arrays and LUNs that have VDS providers. For example, you can use the VDS APIs to create or delete simple, spanned, striped, mirrored, or striped with parity LUNs.
Managing Disks and Volumes
The VDS APIs enable applications to manage disks and volumes. You can create your own application that uses the VDS APIs or use applications such as the Disk Management snap-in or the DiskPart command-line tool (both use the VDS APIs) to perform tasks such as creating or deleting simple, striped, spanned, mirrored or RAID-5 volumes, formatting volumes, assigning drive letters to volumes, and converting basic disks into dynamic disks.
Managing End-To-End Storage Operations
The VDS APIs enable applications to manage end-to-end storage operations. Using the VDS APIs, your application can create a LUN in the storage array, unmask the LUN to a host, create and format a volume on the LUN, and assign a drive letter to the volume.
Technologies Related to Virtual Disk Service
VDS is closely related to the following technologies:
Volume Shadow Copy Service (VSS)
The Volume Shadow Copy service provides an infrastructure for creating consistent point-in-time copies known as shadow copies. The Volume Shadow Copy service can produce consistent shadow copies by coordinating with business applications, file-system services, backup applications, and storage hardware.
Logical Disk Manager (LDM)
The Logical Disk Manager (LDM) provides the drivers and user-mode components that are used to configure dynamic disks and volumes on computers running the Windows XP, Windows 2000, and Windows Server 2003 operating systems.
Virtual Disk Service Dependencies
VDS has the following dependencies:
- OEM Hardware Providers. VDS requires a hardware provider that is supplied by the hardware manufacturer in order to manage storage hardware.
Related Information
The following resources contain additional information that is relevant to this section.
------------------------------------------------------------------------------------------------------------
https://technet.microsoft.com/en-us/library/cc739923(v=ws.10).aspx
How Virtual Disk Service Works
Updated: March 28, 2003
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Virtual Disk Service Architecture
VDS provides three interfaces: a single interface between the application layer and the service, and two interfaces between the service and provider programs in the data layer. The following illustration shows the application-to-service interface and the service-to-provider interface.
Virtual Disk Service Architecture
VDS coordinates with the file-system functions, synchronizes provider activities, and coordinates between applications. Being between the application and provider, VDS presents uniform functionality to applications even though some of the underlying providers might lack such uniformity.
VDS implements the following common functionality: formatting volumes, adding and removing mount points or drive letters, and managing unallocated disks (disks that have no partition information). VDS also returns event notifications to registered applications.
Software and Hardware Providers
VDS supplies two provider interfaces, one for a software provider and one for a hardware provider. Each provider implements a different portion of the VDS API.
- A software provider is a host-based program that is supported by a kernel-mode driver in the storage input/output (I/O) stack. The provider-kernel runtime interacts with the Plug and Play (PnP) Manager at discovery time to claim each disk. Software providers operate on volumes, disks, and disk partitions.
VDS includes two software provider types: basic and dynamic. The basic software provider manages basic disks and offers no fault-tolerant binding. The dynamic software provider manages dynamic disks and offers fault management, where applicable. Software provider behavior is consistent with the behavior of basic and dynamic disks on the host. For example, if the operating system of a given host supports fault-tolerant dynamic disks, VDS also supports fault-tolerant dynamic disks on the host. - A hardware provider is software that translates the VDS APIs into instructions that are specific to the storage hardware. Hardware providers implement the methods used to manage a storage subsystem—a hardware disk array or adapter card that enables the creation of logical disks configured to enhance performance, data availability, or data recovery. Many RAID cabinet manufacturers have produced hardware providers designed for use with VDS.
The capabilities of a hardware provider depend on the capabilities of the underlying storage hardware. Therefore, the degree to which each manufacturer implements the VDS API can vary. For instance, manufacturers can implement as many of the features that are defined in the VDS API as are necessary to optimize hardware configurations, monitor and dynamically tune performance, or automate fault management.
Hardware providers offer several configuration options that are not available to the software providers. The most notable is the automagic configuration model, which presents an attribute-based view of storage to each application. Binding hints, such as “mostly reads” or “fast crash recovery required” replace the complexity of binding physical storage into virtual storage. Each hardware provider performs extent mapping, space allocation, and binding-type selection based on the hints submitted by an application. For the complete hardware provider description, including the available configuration options, see the documentation supplied by your hardware subsystem manufacturer.
Virtual Disk Service Interfaces
Storage management applications can use VDS methods to query and configure host-based disks and RAID storage. Typical storage management applications use VDS to solve configuration management and monitoring problems. These applications range from dedicated storage-management systems to applications that require better control over configuration or fault management. The following Windows Server 2003 applications use VDS:
- The Disk Management snap-in. This snap-in configures and manages disks controlled by a host computer. System administrators and end users can use the snap-in to query and configure local (or remote) disks and volumes.
- The DiskPart utility. DiskPart is a scriptable command-line utility that configures and manages disks, volumes, and partitions. Although DiskPart is available for Windows XP and Windows 2000, these versions do not support VDS.
- The DiskRAID utility. DiskRAID is a scriptable command-line utility that configures and manages hardware RAID subsystems. This utility can interact with any storage hardware accompanied by a VDS hardware provider. DiskRAID ships with the Windows Server 2003 Technical Reference and the Windows Server 2003 Deployment Kit.
VDS objects provide interfaces that expose methods for querying, configuring, and maintaining storage devices, as shown in the following diagram.
VDS Interfaces Architecture
The following tables list the interfaces implemented by the VDS service, the VDS software providers, and the VDS hardware providers.
VDS Interfaces Implemented by Applications
| Interface | Description |
|---|---|
IVdsAdviseSink | Receives VDS notifications. |
Interfaces Implemented by VDS
| Interface | Description |
|---|---|
IVdsAdmin | Registers a provider with VDS. |
IVdsService | Provides service-level methods for working with VDS. |
IVdsServiceLoader | Launches VDS. |
IVdsVolumeMF | Performs access path and file system operations on volume objects. |
VDS Interfaces Implemented by Software Providers
| Interface | Description |
|---|---|
IEnumVdsObject | Enumerates through a set of VDS objects of a given type. |
IVdsAdvancedDisk | Creates and deletes partitions, and modifies partition attributes, such as read-only, hidden, and so forth. Used most often with OEM partitions. For ordinary partitions, use IVdsVolume. |
IVdsAsync | Manages asynchronous operations. |
IVdsCreatePartitionEx | Creates a new partition on a basic disk. Used most often with OEM partitions or for aligning partitions. For ordinary partitions, use IVdsVolume. |
IVdsDisk | Queries and configures basic and dynamic disks. |
IVdsPack | Queries and configures packs containing disks, and creates volumes. |
IVdsProvider | Returns a hardware or software provider's properties. |
IVdsSwProvider | Performs software-provider operations. |
IVdsRemovable | Queries and ejects removable disks, such as CD-ROMs. |
IVdsVolume | Creates and deletes volume plexes, and modifies volume attributes. |
IVdsVolumePlex | Queries the containing volume and repairs bad extents. |
VDS Interfaces Implemented by Hardware Providers
| Interface | Description |
|---|---|
IEnumVdsObject | Enumerates through a set of VDS objects of a given type. |
IVdsAsync | Manages asynchronous operations. |
IVdsController | Exposes methods for performing query and configuration operations on a controller. |
IVdsDrive | Provides methods for performing query and configuration operations on a drive. |
IVdsHwProvider | Provides methods for performing query, re-enumeration, and refresh operations on a hardware provider. |
IVdsLun | Provides methods for performing query and configuration operations on a LUN. |
IVdsLunPlex | Provides methods for performing query and configuration operations on a LUN plex. A LUN plex is the collection of disks that make up the LUN. Except for mirrored LUNs, each LUN can have only one plex. Each plex contains a copy of the data on the LUN. New plexes can be added to a LUN, and, with the exception of the original plex, existing plexes can be removed. VDS supports four LUN plex types: simple, spanned, striped, and striped with parity. |
IVdsMaintenance | Provides methods for performing maintenance operations on a subsystem, controller, drive, or LUN. |
IVdsProvider | Returns a hardware or software provider's properties. |
IVdsSubSystem | Provides methods for performing query and configuration operations on a subsystem. |
Virtual Disk Service Processes and Interactions
Some of the common VDS processes and interactions are discussed in the following sections:
- Managing Servers and Desktops
- Retrieving a List of Providers
- Determining the Number of Controllers on the Subsystem
Managing Servers and Desktops
VDS makes it easy for you to manage the storage on remote servers. Applications that are written for VDS, such as the Disk Management snap-in, use the appropriate services to connect to and manage the storage on those systems.
To remotely manage a computer running Windows Server 2003 from another computer running Windows Server 2003, the following process occurs. The VDS Loader on the first Windows Server 2003 computer loads VDS on the managed computer. VDS calls CoCreateInstance, which passes an interface pointer back to the Disk Management snap-in, which then allows remote management of the computer.
The following diagram illustrates the components that are used when you remotely manage the storage devices on computers that are running Windows Server 2003.
Components Used When Managing Remote Servers
Retrieving a List of Providers
When you manage storage on a server, it is often useful to retrieve the list of hardware and software providers. To get the list of providers, you can use an application, such as DiskRAID, to call CoCreateInstance with the class identifier of the VDS Loader and request the IVdsServiceLoader interface. Using the IVdsServiceLoader interface, the application makes a call to the LoadService() method which loads VDS.
The application then calls the WaitForServiceReady() method to wait for the service to fully load before making other calls. The LoadService() method loads the providers. VDS queries the registry and retrieves the list of registered software and hardware providers. VDS loads all providers listed in the registry. The LoadService() method returns the IVdsService interface, which contains the QueryProviders method. This method returns a COM enumerator interface.
The application then uses the COM enumerator interface to get an IUnknown interface on the provider object (call Next*() on the enumerator interface), and calls the QueryInterface method on the IUnknown interface to get specific provider interface, such as IVdsSwProvider or IVdsHwProvider. This provider interface can be used to query the software and hardware providers and retrieve the providers properties such as the name, type, and version. The following diagram summarizes the process of retrieving a list of providers.
How an Application Gets the List of Providers
Determining the Number of Controllers on the Subsystem
When managing storage on a server, it is often useful to determine how many controllers are on the storage subsystems attached to the server. To determine the number of controllers that are on the subsystem, an application, such as DiskRAID, uses the IVdsService interface to call the QueryProviders method and get a COM enumerator interface. Calling the Next() method on the COM enumerator interface provides an IUnknown pointer to a provider object. The application can call the QueryInterface() method on the IUnknown interface and request the appropriate provider interface, in this case, IVdsHwProvider.
With the hardware provider interface, the application can query the hardware subsystems by calling the QuerySubSystems() method to get a subsystem enumerator interface. Calling the Next() method on this interface returns an IUnknown interface on the subsystem object. The application can then call the QueryInterface() method to request a specific interface, such as the IVdsSubSystem interface. The application obtains the list of controllers for a subsystem by calling the QueryControllers method on the IVdsSubSystem interface. The following diagram summarizes the process of determining the number of controllers on the subsystem.
How an Application Determines the Number of Controllers on the Subsystem
Related Information
The following resources contain additional information that is relevant to this section.
'Windows > 윈도우 공통' 카테고리의 다른 글
| [스크랩] MPSreport 수집 및 항목 설명 (0) | 2018.05.03 |
|---|---|
| [스크랩] 윈도우 시작시 타임서비스 시작하도록 (NTP, timeservice) (0) | 2017.09.14 |
| [스크랩] 윈도우 설치 kb 확인 (0) | 2017.06.28 |
| [스크랩] MSCS 구성간 시간 동기화 (reliable, syncfromflags 옵션 설명) (0) | 2017.04.05 |
| [스크랩] 윈도우로 2G 이상 파일 이동 (0) | 2017.03.13 |