Posey's Tips & Tricks
Adding More Space to Your Virtual Server Disks
Brien shares his experience of beefing up thse size of his virtual drives with physical storage.
Although I have abandoned most of my on-premise production servers in favor of Office 365, I do have a single file server that I use to store all of the stuff that I write, my business records and just about everything else that you can imagine. This server started life running on a physical box and it had been upgraded many times over the years. A few years ago I made the decision to virtualize the server. Today this server is running Windows Server 2008 R2 and is hosted on a Windows Server 2012 server running Hyper-V.
Up until a few days ago, the server had three volumes, each of which mapped to a 2 TB virtual disk. Recently however, two of the volumes began to run low on disk space.
At the time when I built the host server (and the replica server) I installed five 3 TB disks in each. I used one of the disks as a system volume and configured the remaining four disks as a storage array. Using Windows Storage Spaces I was able to make the arrays fault tolerant.
The situation that I found myself in was that I had plenty of physical disk space on the host servers, but the virtual hard disks that were being used by my virtualized file server were too small. I needed to increase the virtual hard disk sizes.
On the surface this task is deceptively simple. You can use the Hyper-V Manager to shut down the virtual machine and then edit the virtual hard disks. I converted each of the virtual hard disks to the new VHDX format and increased each virtual hard disk's size to 3 TB. The Hyper-V Manager made this process really quick and painless. It is worth noting however, that increasing the size of a virtual hard disk does not increase the size of the partitions on the virtual hard disk.
I launched the virtual machine and opened the Disk Management Console. The Disk Management Console reported that two of the three virtual hard disks contained a 2040 GB primary partition, an 8 GB block of unallocated space, and a 1024 GB block of unallocated space. The third partition disk was configured nearly the same as the other two, except that it contained the system volume and therefore included a 100 MB System Reserved partition.
My plan was to simply extend each partition to use the newly available space. Of course this proved to be impossible because the disks were configured as Basic disks and were formatted using the MBR partition scheme. This meant that the maximum partition size was 2 TB.
I really didn't want to convert the basic disks to dynamic disks because I have always heard that you should not configure Hyper-V virtual machines to use dynamic disks. Besides, because the existing partitions were nearly 2 TB in size, all of the usual disk editing options were grayed out (Convert to Dynamic Disk, Convert to GPT, etc.). That being the case, the only way to make the partition larger was to delete and then recreate the partitions.
I decided to create a full backup and then delete a volume. Upon doing so, the Disk Management Console displayed two blocks of unallocated space. One block was 2 TB in size and the other was 1 TB in size. I then right clicked on the disk itself and found that the Convert to GPT option was now available. Upon converting the disk to GPT, the 1 TB and 2 TB blocks of unallocated space were joined into a single 3 TB space. I was now able to create a 3 TB volume. In doing so, I did not even have to convert the disk type from Basic to Dynamic. In fact, I was able to begin restoring data from my backup immediately.
This isn't quite the end of the story though. As you will recall, Hyper-V was configured to replicate the virtual machine to a secondary host server. As you may know, Hyper-V replication actually occurs on a per virtual disk level rather than on a virtual machine level. I have read several articles indicating that the replication process breaks down if you make low level changes to a virtual disk. I am happy to say however, that replication continued to function throughout this entire process and I did not end up having to manually reseed the replica.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.