We’re back for our second episode of the Hyper-V Amigos show cast. In this episode we discuss and demonstrate UNMAP in Windows Server 2012 R2 a bit. As always it was fun to work with Carsten Rachfahl.
Here’s our fun and unscripted (other than the PowerShell used in the demos) attempt at showing you UNMAP behavior with Hyper-V and a DELL Compellent SAN
If you want to read more on our experiences with UNMAP search my blog https://blog.workinghardinit.work/tag/unmap/. I have prepared some links for you.
- Windows Server 2012 R2 Unmap, ODX On A Dell Compellent SAN Demo
- TRIM/UNMAP Support in Windows Server 2012 & Hyper-V/VHDX
- Mind the UNMAP Impact On Performance In Certain Scenarios
- Windows Server 2012 VHDX Thin Provisioning Benefits Explored
I still need to get the slides uploaded, but all that info is in the blog posts.
Enjoy!
EDIT:
In relation to the question below about not much difference between Dynamically expanding VHD/VHDX. That demo didn’t work out so well here so I include some screenshots of a comparison I just ran:
This is the dynamically expanding VHDX. on an IDE controller, no ODX.
This is the dynamically expanding VHD on an vSCSI controller, with ODX.
So yes, losing ODX makes things slower for dynamically expanding VHDX, but it still beats a Dynamically expanding VHD that has ODX. A VHDX is a lot better at dynamically growing than a VHD.
I’m wondering if the performance difference on dynamic vhdx vs dynamic vhd you see in the first test is more about ODX being in effect and less about the performance of dynamic expansion on vhdx vs vhd.
If you disable ODX you would probably see the same performance on dynamic vhdx on scsi as you see at the end of the show when you demonstrate the dynamic vhdx on IDE controller, and in that case the performance numbers of the dynamic vdhx vs vhd are indistingushable here.
But there are definitely other reasons why VHDX is superior and should realy be the only choice .
No, this demo went a bit wrong, not unmap wise but in regards to speed of the expanding VHDX, we normally get around > 200MB/S on average without ODX but it didn’t work out here. The diffence with VHD is very noticable.
As you show, Hyper-V does resize the VHDX when you turn of the virtual machine.
But what if the virtual machine is only restarted (ie during patch cycle), without the full stop?
Shutting down does the trick. A reboot doesn’t seem to. Plan/schedule after patch cycle if you want/need this. I hope this changes in the sense that it becomes an option. In real world scenarios the reuse of empty space in the VHDX will be the biggest benefit. Otherwise you might have to deal with the repeated shrink/grow of the dynamically expanding VHDX. Big permanent data deletions can be dealt with by short scheduled down time. If storage thin provisioning is used, it’s not a big deal anyway.
Little offtopic, but will Win2012 Hyper-V dynamicly release VHDX blocks on storage that is not Unmap aware? I’m thinking about fixed sized local storage with several thin provisioned virtual machines where you wouldn’t need/wish the overhead of full space for provisioning all of them
Yes, the VHDX benefits are there, released block, shrinking. You get all the benefits at the virtual layer. As a matter of fact the screenshots in https://blog.workinghardinit.work/2012/11/20/windows-server-2012-vhdx-thin-provisioning-benefits-explored/ are against an MD3200 without thin provisioning license.
Would there be any differences as far as unmap if the .VHDX files were on a CSV? I’m thinking mainly regarding the ability for Optimize Drivess/defrag unable to run since the volumes are not in redirected mode.
Or would this only be noticeable in a demo environment, where you ran optimize-volume -retrim just to speed up the process. It would otherwise do just fine since the SAN itself would perform these actions at some interval on its own?
The demo VM & all VHD/X files for demo were on a CSV. The background optimization runs automatically, UNMAP happens quite regularly but for demos we run it manually not to waste time, mind you it’s not a defrag, just a retrim command.