Why should I virtualize? It’s a question that’s asked often enough. My response is usually “Why SHOULDN’T you virtualize?”
Virtualization is not a new technology. VMware was founded in 1998. Microsoft released Hyper-V as a major component of Windows server in 2008. As of the writing of this article, the two major players have combined for over 26 years of experience and expertise in the technology. Major companies run virtual servers as integral parts of their operation and anyone can buy the use of one on Amazon or Azure.
“It costs too much...” Actually, it’s free of license fees for many businesses. VMware vSphere Hypervisor can be purchased if you need higher end functions, but the basic product is free of charge. Hyper-V is an included role in Windows Server 2008 through 2012 R2 Standard, Enterprise (2008/2008 R2), and Data Center editions. And if you don’t have those and still want Hyper-V there’s even a free version available from Microsoft that runs a server core installation of Windows with the Hyper-V role which is fully functional including domain join and clustering. Indeed, your choosing to use virtualization can save you thousands of dollars in licensing and power usage as well as cost savings on hardware.
“It’s too complicated…” Well, yes, it DOES add a layer of complexity. However, the basics are easy enough and since it’s both a free and mature technology, from my perspective, you have little excuse not to be spending some time keeping yourself up to date with current technology. If you don’t have experience, GET SOME. Spend a few days playing with Hyper-V and getting the basics of virtualization down – things like setting up a virtual switch, RAM configuration, CPU configuration, virtual disk configuration.
“…I only have a simple workload.” So? The benefits of virtualizing allow you flexibility in your hardware and disaster recovery that you wouldn’t have with a physical installation.
“Virtualization will slow everything down!” True – but only a relative little. Look at your existing servers. Odds are their CPUs are running well under 25% utilization most of the time. And any new server will likely have more cores – effectively more CPUs – and more overall performance. So while virtualization DOES incur a performance hit, in most cases, it won’t be noticeable – especially when implemented as a part of a server upgrade and keeping certain basic performance settings in mind.
So what are the benefits? They can depend on the virtualization platform – Hyper-V or VMware vSphere Hypervisor, for example. Most of the benefits below apply to all virtualization but a few may apply specifically to Hyper-V.
Portability. In the event of a server hardware failure (excluding the obvious storage failure) the system can be moved to a temporary server with relatively little effort. An added benefit this can provide is a reduced need for expensive rapid response warranties on your server. Related, upgrading the hardware when the server ages out becomes a relatively minor procedure as all that need be done is to migrate the VM to a new host.
Expandability. Smaller businesses especially may believe they only need one server but should they discover later that they need another, the potential additional hardware costs can be significantly reduced to perhaps as little as a small RAM upgrade instead of purchasing an additional server at a significant cost as well as the potential to save on a license.
Testing. With appropriate safeguards, you can make a copy of the VM and test planned software upgrades and changes to the server without potentially impacting your network, especially if they fail to work as expected.
Availability and Disaster Recovery. Though potentially a significant investment in both hardware and software licensing, you are ready to implement clustering for high availability and replication for disaster recovery. In one real world example, a New York City small business using Hyper-V Replica established replication of their servers through the Internet to an off-site location in Texas. During Hurricane Sandy, they transferred the functioning of the servers to the replicas in Texas allowing their users to work remotely while the business office was down for days due to a long term power outage.
The flexibility virtualization provides in keeping your business running or quickly recoverable can prevent the loss of thousands of dollars or more in lost sales, worker productivity, and business reputation. It’s an investment that can pay huge dividends.
Pro arguments aside there CAN be reasons not to virtualize. In a production environment, supportability should be considered a requirement. Some products may not be supported in a virtual environment. Some licenses may not permit virtualization. In some cases, applications may require the use of specific hardware that does not pass through or pass through well to the VM. This is not an all-inclusive list - look at your software and businesses requirements and determine if virtualization will be a problem for them.
So which do you choose? Lots of VMware vSphere Hypervisor experts seem to like to argue the VMware product line is both the more mature, more capable and manageable platform. You won’t find many published statistics comparing them, in part because workloads and the host hardware configurations can vary greatly and affect the results of any benchmarking done. There’s also the issue that licensing of the products which can prohibit the publishing of such results unless you can validate your methodology and the vendor approves. That said, most casual reports I’ve read suggest that if there is a performance difference (in favor of VMware) it’s minor. For most people, you simply won’t notice the difference in performance. For the small and mid-size business (the target audience of this article), either should be fine and the management and deployment tools offered for both will likely be more than sufficient in most cases.
I won’t argue against VMware – they produce highly capable products. However, the majority of my experience is with Hyper-V. For small and mid-size businesses, it has one compelling feature which can a huge benefit for disaster recovery – Hyper-V Replica. Introduced with Server 2012 and enhanced in 2012 R2, Hyper-V Replica offers the ability to create a continuous copy (offset by a variable time of 15 minutes or less, depending on configuration and edition) of your entire VM or VMs (as selected) to another Hyper-V server, either locally or remote. VMware offers a similar feature but only through their paid products.
There are some important considerations you should be aware of when virtualizing. Some of them may not be obvious to the inexperienced. Below are some basic recommendations for configuring your VMs.
There are a couple of common misunderstandings when it comes to CPU allocation. First, if your server has a single quad-core CPU, Hyper-V allows you to assign up to 4 CPUs to your VMs. It is NOT EXCLUSIVELY assigning the CPUs. Hyper-V is sharing the assigned CPUs with all other VMs and the host server. If it were exclusive, you wouldn’t be able to have more than 3 VMs on the server (plus the host). Instead it shares them so you could have 20 VMs on the host sharing 4 CPUs. Indeed, that’s one of the purposes of virtualizing – to utilize under-utilized hardware resources rather than let them sit idle.
The second misconception is that the more CPUs you throw at a server, the faster it will be. This is not the case. In fact, if you assign many CPUs to a server, you might cause it to have SLOWER performance. This is because in order for the hypervisor to grant the VM CPU time, it must be able to grant access to the number of CPUs assigned to it at the same exact time. If you had a second VM in a quad core system with a single CPU assigned and a process running at a high CPU utilization, the VM with 4 CPUs would likely perform VERY sluggishly since one CPU was constantly used and delaying the hypervisor from providing access to all the CPUs the VM needed. My rule of thumb is to assign two CPUs to each VM. In servers with 4, 6, 8 or more cores and sometimes multiple processors or hyperthreading (on some Intel CPUs), a system with 2 assigned virtual CPUs should generally perform quite well, almost always able to execute two threads at once and always having a “spare” CPU to handle things should a particular process start hogging the CPU.
Storage & storage allocation
It’s important to keep in mind that a host will have at least two systems operating on its hard drives – the host and at least one VM -- and often more than one VM. So planning storage and RAID is very important. With twice the disk activity – and in some cases, many more times that, SSDs or fast spindle based disks in a RAID 10 or multiple RAID 10s might be required. The extra cost enhancing the disk subsystem of a server is often much less than buying a second server. Always ensure you have the correct hardware to support your drive configuration properly - for example, should you choose to use SSDs in a RAID 10, ensure both the SSDs and the RAID controller used will work together properly.
Hyper-V 2012 and later offer a VHD (virtual hard disk) and VHDX format which are file based hard drives used with VMs. The VHD format has been used for years and offers a maximum size of 2 TB. The VHDX format debuted in Windows Server 2012 and offers sizes up to 64 TB and better data resiliency when access to the drive stops abruptly (such as during a server crash or power failure), and works better with today’s modern 4K disks. In Windows Server 2012, the VHDX format is required when using Gen 2 VMs. Currently, I only use VHDs when I want backward compatibility for Windows Server 2008 and Windows 7, but otherwise I use the VHDX format. For the purposes of this article, I’ll refer both as VHDs and unless you have reason to use them with older Windows operating systems, I recommend using the VHDX format. (VHDs can be converted to a VHDX and vice versa using Hyper-V Manager or PowerShell).
If you are using Windows Server or Hyper-V 2016, you should seriously consider putting the VM storage on ReFS. The new file system introduced in Server 2012 has some added new capabilities in 2016 that can improve the speed of VM backups and Checkpoints.
There are three ways to configure disks in Hyper-V: A dynamically expanding virtual hard disk, a fixed virtual hard disk, and a pass-through hard disk. Each has its pros and cons.
Dynamically expanding VHD/VHDx drives offer the advantage of using only the space they need. This is not a guarantee however. I have seen dynamic VHDs grow in size well beyond their internally used space and shrinking them is not always possible (it’s not automatic at any point and requires the disk be offline). Assuming the VHDs behave themselves, using dynamic drives provide the advantage of being smaller and thus more easily copied/transferred/replicated to other system. Consider that a 600 GB VHD can take an hour and a half to copy at gigabit speeds – 30-45 minutes at best with USB 3 to an SSD, but if only 95 GB is used and hence the VHD size is only 100 GB, it will go much faster. Dynamic VHDs also allow you to overcommit your disk space. Want to allow 5 servers to each see 1 TB of space available when you only have 3 TB of total physical disk? Use Dynamic VHDs and they will.
You do need to be careful when using Dynamic Disks. If they grow to a point that the physical disks fill, Hyper-V will “Pause-Critical” all the VMs that have disks on that volume. If there was nothing else stored on that volume that you could move or delete, you might find it difficult to restore the VMs to a working state. In addition, Dynamic VHDs can fragment if there are any other files on the drive/partition on which they are located, causing a degradation in performance.
Fixed virtual hard disks will occupy exactly as much space as they are to provide (plus a small bit of extra overhead). Using fixed drives prevents issues with fragmentation, “Paused-Critical” events with VMs, and slightly improved overall performance. Their very large size though can reduce your ability to rapidly move, copy, or replicate them to another location.
Pass-through disks can be handy for connecting external USB drives. But they can also cause problems if they are removed from the host without being removed from the VM. They also prevent replication and clustering since the disks cannot be replicated in the same way VHDs can. Generally, I recommend the use of pass-through disks only on a temporary basis.
I generally prefer dynamically expanding hard disks. To combat the possible issues with fragmentation, I sometimes partition the VHD storage drive. This can prevent fragmentation while keeping the file small and technically overcommitted in available disk space. In some cases, I’ve used the FSUTIL command to create several large temporary files - fsutil file createnew v:\file1.tmp 10000000000 - that I could delete as necessary, buying time to order and install additional drives to provide the space needed. This can help prevent difficulty in recovering from “Paused-Critical” states due to disk space, though it can also increase the likelihood of having those events.
Finally, NEVER partition your VHDs. There’s no point. Why create a VHD with a C: and D: partition when you can have TWO VHDs which can subsequently be expanded as necessary and easily through the VM’s configuration and internally through disk management. For every partition you want within a VM, create a VHD.
Windows Server 2008 R2 Service Pack 1 introduced the ability to overcommit RAM in Hyper-V VMs. This can be very useful on hosts with many VMs, but in smaller businesses, it is generally of little real value. That said, I still assign certain VMs RAM through Dynamic Memory while others should NEVER be assigned through Dynamic Memory.
DO NOT use Dynamic Memory on Exchange Servers, SQL servers, or other database heavy servers or with applications that are designed to use all available RAM. Always set these systems to use a fixed amount of RAM.
Use Dynamic Memory on File Servers, RDS Servers, Web Servers, Domain Controllers, and other non-database servers. For these servers, I start each VM with 2 GB of initial RAM (especially at installation) and then I set the Minimum RAM value to 512 MB and the Maximum RAM value to whatever I feel is appropriate for the server OR I calculate the amount I can assign it based on how much RAM is installed in the server. For example, if I have a Domain Controller (DC), Exchange Server, and Remote Desktop Server (RDS) as VMs in a host with 32 GB of RAM, I might set the Exchange Server to 8 GB, the DC to 4 GB max, and the RDS server to 18 GB max. If all servers utilized their maximum RAM, I’d still have 2 GB left over which would ensure the responsiveness of the host.
Microsoft does not license the number of VMs Hyper-V can run. You could, if you wanted, to, using either the free version or the role included with Windows Server, run 1000 Linux VMs (assuming your hardware supported that many). Microsoft requires that any WINDOWS operating system running in a VM be licensed. The Windows Server 2008 Standard and 2008 R2 Standard licenses grant you “1+1” licensing – which allows you to perform one physical install that runs ONLY the Hyper-V role and directly related features and support software and then grants the right to install an additional copy of Windows Server of the same or lesser version in a VM at no additional cost. With Windows Server 2012 Standard, Microsoft altered that license and now grants “1+2” – as with 2008, you can have one physical install, but now you get two Windows licenses you can run in VMs on the same hardware. Need more? Add a Standard license to get two more VMs. And all the while, you could still have your 1000 Linux VMs running next to the VMs running Windows.
There is a point where you don’t want to be purchasing Windows Server Standard licenses. Windows Server Data Center offers UNLIMITED Windows VM licenses but typically costs 5-7 times more. So if you need nine or ten Windows VMs Data Center is the way to go. If you need fewer than that, you likely should purchase several copies of Standard.
And of course, it wouldn’t be Microsoft licensing if they didn’t make it complicated. In addition, each license allows unlimited cores on TWO socketed processors. If you have a quad CPU (four CPUs instead of just four cores), you would need TWO Standard license – or two Data Center licenses.
I’m going to stop there, but keep in mind, licensing can change (it is in Windows Server 2016) and I am NOT a licensing expert – hence my disclaimer:
License information provided here is "best efforts". The comments and descriptions above are based on interpretation of the license agreements and my knowledge of the particular laws and regulations in my geographic location. Laws in your location may invalidate certain aspects of the license and/or licenses can change. "I read it in an article" will not be a valid excuse in an audit. You need to contact the license granting authority to confirm any advice provided here.
One of the biggest complaints about Hyper-V is a lack of USB support. Personally, I do not find this a significant problem. There are few instances where I have missed having USB – in most cases, you can access USB storage through network shares and other devices are rarely needed on servers. One exception might be a modem for faxing – at that would be one of those instances (a fax server) where a VM might not be appropriate. In most cases though, there are substitutes for fax servers – such as internet based services like eFax.
Some Hyper-V Hardware and Software Best Practices - by Philip Elder
Virtual CPUs – The Overprovisioning Penalty of vCPU to pCPU ratios - By Archie Hendryx Hendryx for The SANMAN