If you would like to read the other parts in this article series please go to:
- Getting Used to Using Windows Storage Spaces (Part 1)
- Getting Used to Using Windows Storage Spaces (Part 2)
Introduction
In the previous article in this series, I showed you how to create a storage pool and how to create virtual hard disks within the storage pool. In this article, I want to conclude the series by taking a closer look at the virtual hard disks and how they are used.
A Closer Look at Disk Usage
In order to help you to better understand the way that storage spaces work, I want to take a step back and talk some more about the virtual disk that we have created. If you look at Figure A, you can see the storage pool that I previously created, as shown in Server Manager.
Figure A: Storage pools are configurable through Server Manager.
As you look at the figure above, keep in mind that a storage pool is designed to abstract physical storage from the operating system. With that in mind, take a look at the upper portion of the screen capture. It shows the storage pool that I previously created. You can also see that the storage pool has a capacity of 10.9 TB and that it only has 1 GB of free space.
In this particular case those numbers aren’t as significant as they might otherwise be. When I created this storage space, my goal was to use it to store a single, fixed length virtual hard disk. That being the case, it made sense for me to allocate all of the space in the storage pool to that virtual hard disk. However, this probably is not the most common type of configuration.
In many cases a storage pool will contain multiple virtual hard disks instead of just one. Often times the virtual hard disks are thinly provisioned, which means that they claim only the storage space that they need, thereby expanding dynamically on an as needed basis until they reach their maximum size.
When you create thinly provisioned virtual hard disks, it is possible to over commit the underlying physical disk resources. In this case for example, the physical hard disks within the pool provide a total of 10.92 TB of storage space. If I were to use thin provisioning there would be nothing stopping me from creating a dozen 10 TB virtual hard disks. Obviously the system does not have enough physical disk space to accommodate that much storage, but it doesn’t matter because the virtual hard disks are thinly provisioned. They start out small and grow on an as needed basis. You can add more physical storage to the storage pool when your physical storage begins to reach the point of depletion.
So with that idea in mind, let’s look back at Figure A. As I explained earlier, the top portion displays the storage pool’s total capacity and the amount of free disk space in the storage pool. This information is critically important if you have used thin provisioning to overcommit your storage resources, because you can use it to monitor the rate of physical storage consumption.
Another thing that I wanted to show you in Figure A is the lower two panes. The pane on the right shows the physical disks that are included in the storage pool that is selected at the top of the screen. It is actually possible to create multiple storage pools, but a physical disk can only belong to a single storage pool. In other words, this view of the console only displays the disks that have been added to the storage pool. There might be other disks in the server that are not displayed because they are not a part of the storage pool. In the case of this particular server, there is a fifth hard disk that the system is using as a boot drive.
The pane in the lower left portion of Figure A lists the virtual hard disks that you have created on top of the currently selected storage pool. As I previously explained, my needs required me to create a single fixed length virtual hard disk. Had I used thin provisioning or created a smaller fixed length virtual hard disk, I could have created additional virtual hard disks.
The thing that I wanted to point out about this pane is that the virtual hard disk has a capacity of 8.18 TB even though the virtual hard disk is consuming roughly 10 TB of physical storage space (as reported in the top portion of the interface). This discrepancy is caused by the virtual hard disk’s layout. As you can see in the figure, the layout type is set to Parity. Parity provides redundancy that protects the virtual hard disk against the loss of a physical disk, but this protection comes at the cost of reduced storage capacity. In this case the total amount of capacity lost is the equivalent to that of one physical disk, or 2.73 TB.
Now that I have discussed the way that virtual storage resources are displayed through the Server Manager, you might be curious as to what these resources look like to the rest of the operating system. If you look back at Figure A one last time, you will notice that the virtual hard disk that I have created has been assigned the drive letter F:. With that in mind, check out what happens when you open File Explorer (which was previously known as Windows Explorer). As you can see in Figure B, File Explorer sees F: as a physical hard disk. File Explorer does not make any distinction between C: (which is a physical disk) and F: (which is a virtual disk).
Figure B: File Explorer does not make any distinction between physical and virtual disks.
What is really interesting is the way that the Disk Management Console sees the system’s storage. As you may recall, previous versions of Windows Server used the Disk Management Console as a tool for provisioning physical storage. In other words, the Disk Management Console could see all of the physical disks that were installed in the server and could be used to create things like mirror sets and RAID arrays.
The Disk Management Console still exists in Windows Server 2012, and it still has the ability to see and provision physical disks. However, if storage has been provisioned through the Server Manager then the Disk Management Console sees virtual disks as physical disks. To see what I mean, take a look at Figure C. In the figure, Disk 5 (F:) appears to be a physical disk, but in reality it is the virtual disk that we created through the Server Manager.
Figure C: The Disk Management Console sees the virtual disk (Disk 5) as physical storage.
Conclusion
As you can see, Windows Server 2012 really blurs the line between physical and virtual storage. Even though Server Manager and the Disk Management Console can both be used for storage provisioning, Server Manager is the provisioning tool of choice. The Disk Management Console is a legacy tool that is provided primarily for backward compatibility purposes.
If you would like to read the other parts in this article series please go to:
