available as an option. The answer is that sometimes virtual machines needed access
to volumes and storage that was larger or faster than what was possible with the VHD
format, which had a 2TB limit. Consider a large SQL database: a 2TB limit was too
restrictive, and a performance hit occurred when using VHD above the bare-metal
storage, especially using dynamic VHD, which grows as data is written to it. When
very large volumes with the highest performance needs were required, the Windows
Server 2008 VHD implementation would not suffice, and either pass-through storage
had to be used or iSCSI within the VM. Windows 2008 R2 greatly improved the
performance of VHD, but the 2TB limit remained. This is why pass-through was
required as an option.
In Windows Server 2012, you should never need pass-through storage. There is no
scenario that requires it, because of the new 64TB VHDX virtual hard disk format,
which also features greatly improved performance, effectively matching the bare-
metal storage performance. I’ve never seen a client with an NTFS volume that is 64TB
in size. The largest I have seen is 23TB, because most organizations will limit the size
of an NTFS volume in case a volume becomes corrupt and ChkDsk has to be run,
although this is no longer a problem with Windows Server 2012 and above.
With the need to use pass-through storage removed, all virtual storage assigned from
the Hyper-V host for normal purposes will be through the use of VHDX files. VHD
files should be used only if compatibility is required for pre–Windows Server 2012
Hyper-V or Microsoft Azure. (At the time of this writing, Azure does not support
VHDX, but it may by the time you read this.)
VHDX has other advantages over VHD beyond performance and scalability:
Protection against corruption caused by unplanned power outages, by logging
updates to the VHDX Metadata structures
Alignment with physical disk structures automatically and 4KB sector support.
Alignment was a big performance problem for early VHD, which was caused by the
VHD file geometry, such as virtual sector size, being different from the underlying
NTFS filesystem and disk. Even if the geometry was the same, an offset could exist
between where the VHD started and its header, causing a VHD block not to sit
within a single NTFS cluster but to span multiple NTFS clusters. This makes disk
operations inefficient, because while the virtual OS may think it’s fetching a single
block, many clusters must be read on the physical storage. The good news is that
the alignment issue is resolved in VHDX, which will always align correctly. Details
can be found in the VHDX specification at the following location:
http://www.microsoft.com/en-us/download/details.aspx?id=34750Custom Metadata, allowing management applications to store information such as
the OS running inside the VHDX
Trim support, which enables the efficient reclaiming of blocks on SSD devices