When creating a Virtual Machine, you can select to use either virtual hard disks or physical disks that are directly attached to a virtual machine.
My personal advise and what I have seen from Microsoft folks is to always use FIXED DISK for production environment, even with the release of Windows Server 2008 R2, which one of the enhancements was the improved performance of dynamic VHD files.
The explanation and benetifts for that is simple:
1. Almost the same performance as passthroug disks
2. Portability : you can move/copy the VHD
3. Backup : you can backup at the VHD level and better, using DPM you can restore at ITEM level ( how cools is that! )
4.You can have Snapshots
5. The fixed sized VHD performance has been on-par with the physical disk since Windows Server 2008/Hyper-V
If you use pass-through disks you lose all of the benefits of VHD files such as portability, snap-shotting and thin provisioning. Considering these trade-offs, using pass-through disks should really only be considered if you require a disk that is greater than 2 TB in size or if your application is I/O bound and you really could benefit from another .1 ms shaved off your average response time.
Disks Summary table:
| Storage Container |
Pros |
Cons |
| Pass-through DisK |
- Fastest performance
- Simplest storage path because file system on host is not involved.
- Better alignment under SAN.
- Lower CPU utilization
- Support very large disks
|
VM snapshot cannot be taken
Disk is being used exclusively and directly by a single virtual machine.
Pass-through disks cannot be backed up by the Hyper-V VSS writer and any backup program that uses the Hyper-V VSS writer.
|
| Fixed sized VHD |
- Highest performance of all VHD types.
- Simplest VHD file format to give the best I/O alignment.
- More robust than dynamic or differencing VHD due to the lack of block allocation tables (i.e. redirection layer).
- File-based storage container has more management advantages than pass-through disk.
- Expanding is available to increase the capacity of VHD.
- No risk of underlying volume running out of space during VM operations
|
- Up front space allocation may increase the storage cost when large of number fixed VHD are deployed.
- Large fixed VHD Creation is time-consuming.
- Shrinking the virtual capacity (i.e. reducing the virtual size) is not possible.
|
| Dynamically expanding or
Differencing VHD
|
- Good performance
- Quicker to create than fixed sized VHD
- Grow dynamically to save disk space and provide efficient storage usage.
- Smaller VHD file size makes it more nimble in terms of transporting across the network.
- Blocks of full zeros will not get allocated and thus save the space under certain circumstances.
- Compact operation is available to reduce the actual physical file size
|
- Interleaving of meta-data and data blocks may cause I/O alignment issues.
- Write performance may suffer during VHD expanding.
- Dynamically expanding and differencing VHDs cannot exceed 2040GB
- May get VM paused or VHD yanked out if disk space is running out due to the dynamic growth.
- Shrinking the virtual capacity is not supported.
- Expanding is not available for differencing VHDs due to the inherent size limitation of parent disk.
- Defrag is not recommended due to inherent re-directional layer.
|
Like this:
Like Loading...
Related
Cloudtidings.com 
Thank you very much. This article helped on fixed sizing. I was concerned that a large fixed disk will be a long restore too. I’m thinking of having a standby clone updated on a regular restore routine. What are your thoughts.
ALan
Hi Alan
“standby clone updated on a regular restore routine”. I would not recommend this approach. Instead, you can use SCDPM or other backup software to backup the vhd and if a restore is needed then you can use the granular restore.
One more concern. Snapshots are not recommended for production servers according to the help on 08R2 in Hyper-V.
Example:
Taking a snapshot reduces the performance of the virtual machine while the snapshot is created. You should not use these snapshots on virtual machines that provide services in a production environment.
Has this changed in 08R2 SP1 – and the help comments are not adjusted or what?
Thanks again
Alan
Yes, It can affect performance. It is recommend to avoid snapshots on production environment, as it introduces a potential performance hit, but also additional IO overhead on the disk system (a read can be spread across all disks in the chain, not just the latest – a write affects only the latest – thus extra work for reads as there are more files involved)
But the dangerous/impact of using Snapshots is that the available space may run out on the physical disk that stores the snapshot files. If this occurs, no additional disk operations can be performed on the physical storage. Any virtual machine that relies on the physical storage could be affected.
Again, this not mean that if you have control/management of your environement you ca’nt use it. In some cases it is pretty useful, especially when applying updates. Note: Do not use snapshots for Domain Controllers, Exhange Server, SQL Server