The Microsoft Assessment and Planning Toolkit (MAP) is a free solution accelerator that is intended to aid you in planning for several scenarios. Two of these are server virtualization and desktop virtualization.

The toolkit is an installable application. It is periodically updated, so the best place to look for installation requirements and downloads is on its primary TechNet page: http://aka.ms/map. The tool will run on a single computer and remotely scan all computers that you ask it to. It will store its results in a database; if you don't indicate otherwise, it will create a local instance of Microsoft SQL Server 2008 Express for the purpose. For ease of use and to ensure that the toolkit itself does not interfere with results, it is recommended that you run it from a management workstation and allow it to create the local database.

Not urgent to remove, but this was mentioned in the previous paragraph. The following instructions and images were taken from Version 8.5. If you are using a later version, don't worry. The tool is well-designed and you should have little trouble finding what you need. If you are using an older version, it may not support current products, so you are encouraged to update prior to continuing.

To use MAP to prepare physical machines for deployment as Hyper-V Server guests:

The most comprehensive way to plan for the existing physical loads is to track their performance in Performance Monitor. If you're not familiar with this tool, turn to the chapter on performance monitoring for usage instructions. As you would with MAP, use a fairly idle computer to collect performance metrics from the systems you plan to virtualize and have it track all systems for a representative amount of time. One to two weeks usually provides a fairly accurate performance picture. Unlike MAP, Performance Monitor only works on Windows systems. Third-party monitoring tools are also available if Performance Monitor cannot provide the results you need.

The Performance Monitor metrics that are of most value are as follows:

The above metrics were taken from a Windows Server 2012 computer; other Windows versions may be somewhat different, but they will all have similar objects. Also, there may be value in getting separate read and write measurements from disk objects and separate send and receive measurements from network objects. This is because there are ways to balance disk and network configurations that favor one over the other. Balance is usually preferred in a virtualization environment due to load variety, but if your workloads seem to favor a particular direction, you may choose to architect to accommodate that.

Of course, these metrics are generic in nature. If you anticipate a certain need that these metrics won't capture, feel free to design any tracking method that monitors the objects you are interested in. For instance, if you are considering the migration of a specific application and not its entire server, you can set monitors on that application's activity. Additionally, applications can create and register their own counters that Performance Monitor can track. Active Directory and Exchange Server are among these.

What you're mostly interested in is how the machines behave on average. Peak activity periods will come and go, but unless they are sustained you may not want to consider them too strongly. For instance, if a CPU spikes to 100% for three or four seconds ten times a day and is otherwise idle, there is no need to consider that a heavy load. If it hovers above 80% for an hour, that is probably substantial.

If there are periods of high activity, ensure that you understand what they are before adjusting your plan to accommodate them. As an example, you may find regular intervals of very high disk activity. If you simply size a disk subsystem to handle the load, you might find that you have spent extra money on a high-powered SAN just to speed up backups that occur when no one is using the system anyway.

Also, remember that your cluster will be a shared resource environment. If you determine that twenty separate systems need a combined 2,000 disk transfers per second on average but did not note that their peak workloads never occur simultaneously, you may inadvertently oversize your system.

Your primary goal with memory metrics is to determine how much memory to allocate to a system once it is virtualized. The easiest way seems to be to compare how much physical memory it has to how much physical memory it uses. However, this simple metric may hide a memory starvation issue. If the Pages/sec metric is high and available memory is low, the machine may not have enough physical memory. You could also track for page file usage, but unfortunately this isn't a great metric for determining just how much extra memory the system needs. If possible, try to resolve this prior to virtualization. If it is not possible, make a note that this load will probably benefit from additional memory once virtualized.

Conversely, if available memory is high and remains high, the system has more memory than it needs to perform its role. You may consider reducing the memory assigned to it once it is virtualized. Chapter 7, Memory Planning and Management, contains many additional details about memory, including how to use Hyper-V Server's Dynamic Memory feature for workloads with varying demands.

These are fairly straightforward and easy to understand. Systems with high networking utilization need to be carefully considered as they may not make the best candidates for virtualization. Hyper-V Server 2012 can employ quality of service controls to keep them from choking out other systems, but they may be best left on their own systems. However, if you have one high utilization system among many low utilization systems, teaming with a system with ten-gigabit or greater will probably be sufficient. Also, keep in mind that you are likely to encounter systems with 100 Mb adapters and possibly even 10 Mb adapters. Their usage will change once placed on a gigabit-capable system.

Disk space consumption is usually the largest concern, but you won't use Performance Monitor for that. The next things you'll want to determine are how much data your disks are moving and how many read/write requests they are performing. These two metrics are not necessarily tied together; it is certainly possible to have a high number of read or write requests that move very little data.

If disk activity seems very high, first ensure that it is not due to memory paging. Heavy paging loads place the burden on the disk.

% Disk Time isn't normally useful by itself. If it is a very low number, then you probably don't need to spend a lot of time digging into the other metrics. The Avg Disk Queue Length metric tells you if your disk system is able to keep up with the load. Usually, if it is consistently above two, there is a problem that needs to be addressed; in many cases, it is actually a sign of insufficient memory. The remaining two, Disk Bytes / sec and Disk Transfers / sec, tell you how much data is being moved and how many moves are occurring, respectively. The latter is a rough estimate of input/output per second (IOPS).

Translating disk numbers from disparate systems into a single set of numbers to size shared storage is extremely difficult. Disk activity usually occurs in spikes, and it is very rare for multiple systems to spike simultaneously. Do not simply add up all the transfers per second and bytes per second and attempt to purchase a system that meets it; such a system may be prohibitively expensive and it will almost always be idle. If you are considering a SAN, many vendors have tools that can help you size for this purpose. Be aware that even the best of those tools are factoring in some guesses.

The processor measurements are more straightforward but potentially misleading. Sustained high CPU time is what you want to watch for. A high load does not indicate that assigning additional virtual CPUs will be beneficial, but it does indicate that a virtualized instance will probably consume a noticeable amount of CPU time. A high number of active threads may indicate that the system may benefit from more vCPUs when virtualized. Not all applications benefit from having multiple virtual CPUs available; some perform best with only one. You may need to consult with your application vendor's support team or with other organizations who use the product to learn how any given software will behave.

Some applications lean the other way, benefiting not only from additional vCPUs, but from Hyper-V's NUMA-awareness to keep a virtual machine's memory near the physical CPUs that are accessing it. NUMA will be explained in Chapter 7, Memory Planning and Management.