When running a test lab on a tight budget it’s a challenge to get the most out of the available CPU, RAM and storage. Over the last years I learned some nice tricks in order to run the maximum amount of VMs on my test lab, and still having an acceptable performance.
Please be reminded, this approach of combined ‘tricks’ is only viable in test labs and shouldn’t be used in any production environment at any times! And no, I am NOT responsible for your test labs in any kind of way…
Some ground rules first
Here are some basics in order to get the most of the available hardware of your testlab.
- Run the parent Windows Server OS hosting the Hyper-V role from a ‘classic’ disk (no SSD) which has good performance (10K and lots of cache);
- Put the ISO and other software store on the classic disk;
- Run all the VMs from the availble SSDs, never ever from the ‘classic’disk!;
- Same goes for storing the meta data and memory of your VMs. Store them on the available SSDs, never ever on the classic disk.
Resource saver 01: Differencing Disks
When using differencing disks for ALL the VMs running on your test lab system, you save a LOT of storage. The parent disk contains the server OS and the differencing disk contains the delta’s for that particular VM. For instance, the VM running SQL will have a differencing disk containing the SQL installation and DB files, but use the parent disk running the server OS, containing between 9 to 14 GBs of data.
That parent disk will be used by all other VMs, resulting in MASSIVE disk cost savings per VM.
How to create a parent disk? That’s easy!
- Create a new VM
- Install Windows Server (2016 for instance)
- Configure it as required (time/date settings and so on)
- Install the latest updates
- Run SysPrep with this syntax: sysprep.exe /oobe /generalize /shutdown /mode:vm
- The VM will shutdown itself when done with sysprep
- Copy the related VHDX file to a new folder, like D:\_Differencing Disks
- Rename the VHDX file so you know exactly what this file is all about (eg: WS2016-DiffDisk-Std-GUI.vhdx for WIndows Server 2016 Std with Desktop Experience and WS2016-DiffDisk-Std-CLI.vhdx for Windows Server 2016 Std without Desktop Experience);
- Set the VHDX file to be read-only.
Now you’ve got yourself a nice parent disk. Read this posting in order to roll out a VM using this parent disk.
Resource saver 02: No GUI!
Yes, I know. Many Windows users are used to clicking through windows. Hence the name of the OS! BUT when running Windows Server 2016 Std without a GUI as a parent disk, one saves 4,5 GB compared to a parent disk hosting Windows Server 2016 Std with a GUI (Desktop Experience).
When running MANY VMs and as much of them using the no GUI version, one quickly saves tens of GBs!
Besides that, one learns how to work with Windows Server 2016 without a GUI, which is a good thing as well. Ever heard of the utility sconfig? It’s powerfull and helps one out with the basic configuration stuff:
Resource saver 03: Deduplication
Wow! This feature is totally awesome. And pretty easy to use on your Windows 2016 server hosting all the VMs. Simply add this Role (File Server > Data Deduplication) to your server:
Let it run as long as it takes. With PS cmdlet Get-DedupJob you’ll see the progress of the running dedup job(s).
When dedup is ready, fire up the VMs and you’re back in business! And of course, all these steps can be scripted with PowerShell as well. And this PS script can be scheduled as required.
Resource saver 04: Dynamic Memory
With dynamic memory you can squeeze the maximum utilization of the available RAM. And even ‘more’ when using Windows Server 2016 WITHOUT a GUI. Since this OS edition has a far lesser footprint on the available resources.
As such you can run VMs hosting AD domain controllers and DNS with only consuming 675 MBs of RAM! And with the dynamic memory config you can set the limit to 1024 MB max.
This way you get the most of the available RAM of your Hyper-V server.
Sure, everything can be put into the cloud. But guess what? Running 20+ VMs in Azure isn’t cheap. One saves a LOT of money when hosting those same VMs on an oversized desktop as a testlab .
When using it smart with all the resource savers I mentioned before, you’ll squeeze the max out of it, while still having a reasonable performance.
And when combined with Splashtop you can remotely wake up the testlab when required (some additional one time router configuration is needed here). As such this testlab doesn’t have to run 24/7 but is only fired up when required.