How Virtual Disk Service Works

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

Interfaces Implemented by VDS

VDS Interfaces Implemented by Software Providers

VDS Interfaces Implemented by Hardware Providers

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.

• Disks and Volumes

• Basic Disks and Volumes Technical Reference

• Dynamic Disks and Volumes Technical Reference