Top Ten: Virtualization Mistakes

Virtualization has become a core infrastructure technology for almost all businesses today. It's so prevalent that many organizations plan for virtualization of all new server deployments. One factor that has allowed virtualization to become so popular is its ease of implementation. However, that same easy setup can come back to bite you if you don't plan your virtual deployments properly. In this column, I'll point out the top ten virtualization mistakes you should avoid.

10. Virtualizing on older hardware—Both Microsoft Hyper-V and VMware's ESX Server can run on older hardware platforms. However, newer processors have features such as Second Level Address Translation (SLAT) and Nested Page Tables (NPT) that can drastically improve virtualization performance by letting the hardware take care of the translation between the guest virtual machine (VM) memory addresses and the physical RAM addresses.

9. Running antivirus on virtual hard disks—Implementing antivirus protection is always a good idea. However, antivirus scans on a VM's virtual hard disk can degrade the performance of the VM. Be sure to exclude virtual hard disks from the host's antivirus scanning.

8. Ignoring guest VM backup—You can back up the VM at the host level without interrupting end-user services, enabling easy disaster recovery because you can restore that host image on another virtualization host in a matter of a couple of minutes. Even so, host-level backups can't be considered a substitute for guest backups. Applications such as Microsoft SQL Server and SharePoint need to be backed up at the guest level for end-user data protection.

7. Inadequate virtualization host security—It's easy to focus on guest security and forget that securing the host is even more important because the host has access to all the guest resources. Virtualization hosts must have physical security, plus all the resources on the host should be secured according to the principles of least privilege.

6. Always using the VM default settings—Another common mistake is to blindly accept the default settings used by the virtualization host and the VM management console. For example, I commonly change the default VM location from DAS to SAN. In addition, you need to take care to size each VM's CPU, RAM, disk, and network to match the workload required by that VM.

5. Inadequate host processor resources—Virtualization lets you achieve much higher hardware utilization rates than you can reach with a physical server. However, nothing stops you from overcommitting your host CPU with too many virtual workloads. Ideally you want to have one host CPU core per VM. Windows Server Resource Monitor can give you a quick heads up about your CPU and core utilization levels.

4. Inadequate host RAM—Lack of RAM will definitely have a significant impact on your virtualization environment—even more so than lack of CPU resources. RAM is the primary limiting factor to the number of concurrently active VMs because each VM must allocate its RAM from physical memory. Make sure you have an adequate amount of host RAM for the number of VMs you plan to run as well as leaving enough RAM for the virtualization host.

3. Inadequate host network adapter cards—Another common mistake—especially in server consolidation projects—is failing to install an adequate number of network adapter cards in the virtualization host. In a server consolidation environment, all of the network bandwidth from the VMs is funneled through the host's network adapters. Although you might not need a one-to-one relationship, it's easy to overcommit a few network adapters with the traffic from many VMs.

2. Too many VMs per Cluster Shared Volume—Cluster Shared Volumes (CSVs) are a new feature in Windows Server 2008 that lets multiple VMs share the same LUN. By default, all VMs go to the same CSV. This design can be OK for light workloads, but heavier workloads, such as SQL Server, require more CSVs. In addition, remember that disk performance depends on the number of spindles, so using storage with a large number of spindles provides better performance.

1. Thinking you can use only one CSV per VM—It seems common to think that a VM is limited to using one CSV. Not only can you create more than one CSV per virtual server, but you can also split your VM's VHD files between CSVs. You could split your system files and page file to a VHD on one CSV volume and put your data files and user data in a VHD file located on another CSV volume.

Related Reading: