This is a follow up to my article Catch Up: Expanding Your Laptop With Hyper-V, where in this post I want to explore why you would use Hyper-V and what its limitations are.
Limitations first: Hyper-V on a Windows client is not as fully featured as its bigger brothers, Hyper-V Server and Windows Server. This is NOT a licensing play, as Hyper-V is free, rather it is simplified for the likely use cases on a desktop. It’s also important to remember that if we are using Hyper-V in the data centre then it is the only role running on the base operating system, whilst on our desktops we will be using that base operating system for all sorts of stuff from Office to Online gaming.
Developers writing for Windows running on a phone use Hyper-V by default, as Visual Studio uses Hyper-V to spin up an emulator to spoof the code running on a phone. This technique might also be appropriate for other kinds of development, however, we have to do that ourselves. Here’s some reasons why that might work for you:
- Spin up a Windows or Linux server running IIS or Apache and then use your base OS as the client accessing the site
- You could have a set of modestly sized VMs with combinations of browsers to check your site works on all of them
- You could create a single VM for SharePoint development and turn it off when not in use to get resources back for your base OS
Any other testing and development requiring access to services and software that won’t run on your client OS.
- In the world of IT Pro you might want to test PowerShell and how to connect remotely to it
One other thought occurs: in order to get certified you’ll only stand a chance of passing if you are using the technology – even if that’s in a sandbox. TechNet does have Virtual labs, but these don’t persist, so if you want to have a set up to return to then Hyper-V might be the answer.
A few other notes and queries
Hyper-V is a type 1 hypervisor which means it uses the full capabilities of the virtualisation on your CPU (which is why it is a bit harder to setup). Remember when your VM’s are running you are sharing memory, networking and disk across these and the base OS, so ideally you want 8Gb RAM, i5 or better CPU and most importantly SSD for storage. If not, try out the guest OS on a different physical disk from the VCMs
Licensing is needed for each guest OS whatever the virtualisation solution you use. Your base OS is sorted as I am assuming you are running Windows 10, but the OS in the guests’ is going to need keys – be that Windows Server client or something else. However, as these are for test, I suggest you use the evaluation keys and get clever with creating sandboxes for this kind of work, where your data can persist and survive being moved to a new VM. The trick is to make your setup like Azure and only have the base OS and application on your base Virtual Hard Disk (VHD); then store your data on a separate VHD – e.g. SQL Server databases, Active Directory (stored in c:\windows\NTDS by default), and so on. You’ll then need to get good at rebuilding your sandbox when needed – I have a whole series on this called LabOps.
A final thought
All of the stuff I have described here could be characterized as DevOps, except that it’s just going to be for you working by yourself, and learning parts of this process to make your own life easier!