The Basics of the Virtual Disk Services (VDS)
Back in Windows 2000 Server days, managing SAN-based storage in Windows was mostly up to your SAN vendor. You would typically need to load a tool to manage your storage device (either graphical or command-line) or sometimes use a web-based application. If you had multiple storage arrays, you would likely need to handle different user interfaces, terminologies and tools. Your experience could vary widely from vendor to vendor. At that time, centralized management of multiple networked storage solutions would be very hard, if at all possible.
That changed with Windows Server 2003, which introduced the Virtual Disk Service (VDS), a Windows service for managing volumes. Administrators now have a single interface that works with different vendors, if that vendor supplies a VDS hardware provider for their networked storage device. This same interface also works with directly attached storage, providing a unified view of all disks and volumes, regardless of being connected via SCSI, Fiber Channel, iSCSI or PCI RAID. VDS exposes the complex functionality provided by these storage hardware vendors and scales up to enterprise configurations.
If you like GUIs, you can use Window’s the Disk Management MMC (dskmgmt.msc) to see all disks available, create/format volumes and mount them on a drive letter or path (mount point). With Windows Server 2003 R2, you also have the Storage Manager for SANs (sanmmc.msc), which is a GUI to manage SANs exposed via VDS, including things like discovering devices, creating LUNs and exposing them to specific hots.
If you need to automate using a command line, you can use the DISKPART, DISKRAID and MOUNTVOL command-line tools. DISKPART (diskpart.exe) is focused on managing partitions, volumes, file systems and mounting points. It offers a way to create/delete partitions on existing disks, create/delete volumes on those partitions and mount them on a drive letter. You can also configure dynamic disks and the software-managed fault tolerance (like mirroring and RAID5) using this tool. Details on the DISKPART command can be found at http://support.microsoft.com/kb/300415. If you’re using mount points instead of drive letters, you also need the MOUNTVOL (mountvol.exe) command-line tool.
DISKRAID (diskraid.exe) is the other command-line tool focused on hardware RAID subsystems, which lets you check information about your storage infrastructure (like subsystems, providers, HBAs and ports), create/delete LUNs, configure the hardware-managed fault tolerance (like mirroring and RAID5), associate a controller port with a LUN, mask/unmask LUNs to specific hosts, etc. DiskRAID also supports management of your iSCSI initiator. You can find details on the DISKRAID command at http://technet2.microsoft.com/windowsserver/en/library/1d39cdeb-f3ec-4e75-8ab3-c5ea47e230cb1033.mspx.
Beyond the storage administrator perspective, there are at least two additional points of view related to VDS. If you are a hardware vendor, you are probably interested in writing a provider to expose your capabilities using the Windows VDS interfaces. From a storage management vendor perspective, you can use VDS as an API to work with your Windows systems, saving you the effort to write specific code for each hardware vendor. There is developer-focused guidance on how to write VDS providers and how to call the VDS API to manage storage at http://msdn2.microsoft.com/en-us/library/aa383063.aspx.
Storage vendors still provide management interfaces that are specific to thier hardware products. However, with the increased support of the VDS APIs and tools, you should see more Windows Server administrators, hardware providers and management tools leveraging this built-in ability of the Windows OS. You can find more information about VDS at http://technet2.microsoft.com/windowsserver/en/library/1dbc6c24-1477-4f73-a0ae-57b4e90808d81033.mspx