ltstudiooo - Fotolia
There are a number of files associated with a virtual machine running on Hyper-V, including XML files, virtual hard-disk files and snapshot files. XML files hold the configuration information about the virtual machine. Virtual hard-disk files hold the guest operating system and application data. Microsoft Hyper-V supports two types of virtual hard-disk files: VHD and VHDX. The VHD file format has been available since the first release of Hyper-V, whereas the VHDX support was added to the Hyper-V role on Windows Server 2012. When you create a virtual machine on Windows Server 2012 and R2 Hyper-V hosts, you are presented with the two types of virtual hard disks: fixed and dynamic.
Fixed VHD/VHDX: In the case of a fixed VHD or VHDX, Hyper-V pre-allocates the required disk space on the host. For example, if you create a VHD/VHDX file of 127 GB, Hyper-V creates a file of that size on the path you specified when creating the virtual hard-disk file. This is sometimes called thick provisioning, in which the space for the virtual hard-disk file is reserved on the Hyper-V storage.
Dynamic VHD or VHDX: When it comes to dynamic VHD/VHDX files, Hyper-V allocates the required space only for the file metadata of the virtual hard-disk file. For example, if you want to create a VHD/VHDX file of 127 GB, Hyper-V initially creates a file of only 4 KB, but will allow the file to grow up to 127 GB in size. This is sometimes referred to as thin provisioning.
So far you have a bit of understanding of virtual hard-disk types supported by Hyper-V, but the question still remains the same: Which virtual hard disk is right for production workloads? As indicated in Table 1 below, the performance of a fixed VHD/VHDX file is always good, because VMWP.exe, a separate process implemented for each running virtual machine (VM) on the Hyper-V host, does not really have to worry about making sure the VHD/VHDX file grows as and when needed. In other words, the virtual hard-disk file does not suffer from too much I/O operations (IOPS).
The case of using a dynamic VHDX files in a production environment is completely different. Microsoft always recommended the use of fixed VHD over dynamic VHD files in early versions of Hyper-V. Starting with Windows Server 2012 Hyper-V hosts though, Microsoft actually recommended implementing dynamic VHDX files for production VMs. However, there are a few caveats to this. The common misconception about dynamic VHDX files is that they are faster. It is true that the dynamic VHDX format uses “larger blocks” to grow as the data is added to it, but there are more IOPS when this growth takes place. Dynamic VHDX files extend when the VMWP.exe process realizes that there is no more room to store the data. The process checks if it needs to grow or not (causes I/O and CPU cycles) first and then checks if there is room elsewhere on the file or not (causes more I/O and CPU cycles). The whole process puts burden on the VMWP.exe process, which causes more IOPS on the dynamic VHDX file and CPU processor time on the Hyper-V host. The dynamic VHDX file using metadata for updating/logging data is also a common reason that leads to more I/O and CPU cycles.
You may or may not want to use dynamic VHDX files in a production environment depending on the applications running inside the VM. For example, if you run resource-intensive applications -- such as SQL and Exchange -- inside a VM, you must pay particular attention to the application's resource requirements.
The first question is why would people want to use a dynamic VHDX? The obvious answer would be to the user is trying to save disk space. So the discussion actually leans towards saving disk space or gaining performance for applications running inside the VM. The way I address the use of dynamic VHDX files in a production environment is by considering the application's characteristics. When it comes to deciding whether to choose dynamic VHDX or not for production workloads, it is important to look at what applications you are going to host in the VM. You might have two different types of applications running in the VM.
Case 1: Applications running inside a VM heavily performs I/O operations
If applications running inside the VM perform continuous read and write operations on the dynamic VHDX file, it is recommended that you choose a fixed VHDX. This is not a hard recommendation. If you are hosting dynamic VHDX files on an SSD storage, you can use dynamic VHDX files for production workloads. However, sometimes it is necessary that you pay attention to the application's requirement. For example, since an SQL application performs too much read/write to the disk, I have seen customers implementing SQL VMs on a fixed VHDX disk.
Case 2: Applications running inside a VM do not heavily perform I/O operations.
If an application running inside a VM doesn't perform too much read and write operations to the dynamic VHDX file, the use of dynamic VHDX is recommended. If you think performance is negligible, then consider using dynamic VHDX. Using Dynamic VHDX helps save disk space, but you could run out of disk space if you haven't planned for that much storage growth. It is also necessary that you are notified of disks running out of space by implementing disk-monitoring software.
So far you have the virtual machine hard-disk files stored as VHD or VHDX. Hyper-V also supports attaching a physical disk directly to the VM, which is called pass-through disk. The pass-through disk does not use a virtual hard-disk file, but rather a local disk attached to the Hyper-V host or a disk as a LUN from a SAN attached to Hyper-V is made available to the VM. Although pass-through disk performance is still considered best among fixed and dynamic VHDX, it still has a few limitations. First, you cannot perform snapshots. A second limitation is that VM using a pass-through disk cannot use the "shared nothing live migration" feature. Although live migration is still supported for VMs using the pass-through disks, it must be configured as a storage disk resource in the Hyper-V cluster.