Thin-Fixed VHD’s

Alex Jauch -- Architect, Microsoft Private Cloud


As we have previously discussed on this blog, the PowerShell Toolkit provides the ability to create “Thin-Fixed” VHD’s.  To refresh your memory, these are fixed size VHD’s which have had their zeros unmapped on the storage controller.  This means that we have flexible provisioning like a dynamic VHD but the performance of a fixed VHD.  There are a couple of interesting benefits to this technique.  One, these VHD’s are inherently space efficient.  No more “captive” white space in your .VHD files.  The storage controller will only allocate storage for them as they are written to.  This is exactly what we do for a  thin LUN, just at a file granular level.  Second, these files are much faster to create  than traditional fixed VHD’s.  This is because the zero unmap operation is much more efficient than the write zero operation that is traditionally done to create them.


In the table below, we see a comparison of file creation times between Fixed VHD’s and Thin-Fixed (in seconds):


1000Gb3354 (1hr)16

As you can see, the difference can be as high as 100x faster for Thin-Fixed VHD creation.  What is probably more important is that it brings the creation of fixed VHD’s down to a time interval short enough that there is really no reason to use Dynamic VHD’s any longer.  This will improve the overall performance of your storage system and the Hyper-V systems it supports.

To highlight this tool and the performance advantage we offer, we created a demo on YouTube.  Please let us know what you think!


Thanks for the good explanation Alex. Excellent video. 

Got me wondering how this works with the instant file initialization option available since SQL Server 2005/ Windows 2003 that does about the same thing at the database file level? Any conflicts between the two? Would it somehow be better in some way to NOT use the Windows policy switch? Does it even matter?

Thanks. Bill Wunder

jausch Netapp Alumni

Yes, this is a very similar concept.  In SQL when you choose "instant file initialization" SQL simply refrains from the expensive write zero operation that is normally used when creating database files.  In our case, since we have already zero'd the VHD by unmapping the blocks, you are guaranteed to only get zeros upon read.  In the case of SQL server there is no such guarantee since it's done at the file system level.

If you were running SQL inside of a VM against a VHD that was Thin-Fixed, any block that SQL writes zeros to as part of file creation would be mapped by Data ONTAP just like any other write.  This would create "white space" for those blocks until they are used by SQL.  In that case, using instant file initialization would ensure that you didn't use any more space than is actually needed. 

In summary, I would consider these techniques to be complimentary rather than mutually exclusive.