One of the greatest features of server virtualization is the ability to migrate physical server workloads to virtual servers. This physical-to-virtual (P2V) migration option enables you to retire aging servers, thus reducing the number of physical servers necessary in a data center. Reducing the amount of space used, power, cooling, hardware and licensing costs without sacrificing performance is especially appealing. But there are limits...
to which workloads can be virtualized, and the process of choosing which ones is critical to maintaining a stable server environment.Gathering data on server workloads
So how do you identify which workloads to migrate to a virtual server? Gather accurate trending data over a period of time to get a true profile of the physical server workload under consideration. And to do get this trending data, you need a monitoring or trending tool. The tool can vary, but you need data that most accurately represents the average workload of your physical system. The longer you can monitor performance trends, the more accurate an assessment of resource usage will be. I commonly collect two to six weeks of trending data before deciding whether to migrate a physical server to a virtual environment. Physical servers that have higher resource utilization in particular require longer monitoring periods.
As you analyze your server workloads, I recommend looking at the following factors:
- RAM utilization
- Average CPU utilization
- Disk space utilization
- Disk I/O (read and write)
- Network (read and write) utilization
There are many different monitoring and assessment tools to gather this information. Here are a few monitoring tools that I have used in determining which physical servers will be good candidates for a virtual environment.
Microsoft Assessment and Planning Toolkit 4.0 (MAP Toolkit): Along with many other functions, the MAP Toolkit can gather critical resource-utilization data about a proposed physical server. Raw data is helpful for virtualizing a single physical server, but this tool goes further by gathering data from multiple physical servers and recommending how many Hyper-V hosts are needed to house those servers if they were migrated into a virtual environment. In my experience, the recommended number of virtual machines (VMs) per host is conservative. For administrators new to virtualization, this provides a good starting point.
Microsoft Performance Monitor (Perfmon): This trusty standby does a pretty good job in short-term (i.e., one-to-four-week) trending of data.
Cacti: I use Cacti to get basic data about CPU usage, disk performance and use, and network utilization. I have used mostly monitoring based on Simple Network Management Protocol (or SNMP), but other plug-ins extend its monitoring ability. This tool is equally good at trending Microsoft and Linux workloads being considered for Hyper-V and other hypervisors.
Other enterprise solutions: Monitoring tools such as System Center Operations Manager and PlateSpin Recon can provide a wealth of trending data about proposed P2V candidates. Some can even recommend servers that would be good candidates for virtualization.
So now that you have gathered resource utilization data, what does it mean? How does this translate into knowing whether a physical server is a good virtualization candidate? How do you know how many VM slots are available on a particular host? Below are my recommendations that have evolved from my experience with Hyper-V environments. These are broken down into tiers A, B and C, each with increasing resource utilization.
With these tiers in mind, consider these two resources as you determine the number of VMs to migrate to a particular host. RAM is important because all VM-allocated RAM must be reserved in Hyper-V. Disk I/O is important because, depending on your disk subsystem, it can create a performance bottleneck.
That said, I base VM slots per host primarily on RAM since without RAM pooling in Hyper-V, this is often the resource that is depleted first on the host.
Example of maximum available VM slots: Host with 64 GB of RAM
Note: In the case of tier-C servers, 15 virtual machines would theoretically work. In practice, this may be a bit optimistic. I recommend splitting tier-C VMs between host servers for the best performance.
Before you undertake a P2V migration, determining the resource utilization of a particular physical workload is critical. Accurately trending the data translates into your ability to tier a physical workload. This process has far-reaching consequences for the future stability and predictability of a virtual server environment, so take the time to get it right. The steps above are more than just guidelines for P2V migrations; they can also be used for new workload installs. Every new workload that you can avoid moving to a physical server and install directly as a virtual workload can help reduce data center space, power, cooling, hardware and licensing costs.
About the author
Rob McShinsky is a senior systems engineer at Dartmouth Hitchcock Medical Center in Lebanon, N.H., and has more than 12 years of experience in the industry -- including a focus on server virtualization since 2004. He has been closely involved with Microsoft as an early adopter of Hyper-V and System Center Virtual Machine Manager 2008, as well as a customer reference. In addition, he blogs at VirtuallyAware.com, writing tips and documenting experiences with various virtualization products.