Not every application can run in a virtualized environment. A very common reason is a dependence upon a piece of hardware that cannot be virtualized. Anything that requires access to a PCIe slot, a serial device, or a specific piece of parallel-connected equipment will likely be difficult or impossible to virtualize. As it fits within the Microsoft paradigm, a virtualized operating system needs to be portable between hosts without specific ancillary configuration requirements from one host to the next. These types of devices preclude that portability. Fortunately, there are ways to accommodate some types of hardware, such as USB devices. There will be a section on that later.

Application vendors, even Microsoft, may require a specific environment for their software in order to continue providing support. There are many reasons why a software company may not wish to certify their applications on a Hyper-V Server cluster, so you'll need to contact those whose products you use to ensure that you'll continue to have access to the needed support lines.

Even if your vendors have already certified their applications on a standalone Hyper-V Server host, it does not necessarily follow that they will extend that support to a cluster environment. One such example is Microsoft Lync Server. Technologies like Live Migration appear to have no downtime because the normal disconnect time is less than the standard TCP/IP timeout. Even though it's brief, there is a break in service. This can cause problems for some applications.

Microsoft's application-specific support policy in regards to virtualization is viewable on their knowledgebase at http://support.microsoft.com/kb/957006.

There are some non-technical investigations to be made. Clustering of physical resources expands the reach of your hardware that is dedicated to virtualization. An argument can be made that the traditional reasons to segregate resources onto separate hardware platforms are no longer relevant. You might be able to inspire other departments to join in on the project. This could bring additional resources and an interest in some of the more advanced technologies that Hyper-V Server and Failover Clustering have to offer. There may also be internal reasons to bring others onboard.

Like any other major project, a Hyper-V Server cluster deployment is performed in phases. Each phase is composed of a number of subsections and steps. Setting timelines for these phases helps to frame the project for others, establishes reasonable expectations, and adds another dimension of focus to the project that can help keep it from falling to the wayside or getting mired in side projects. Typical phases for this type of project include planning, design, initial setup, pre-deployment testing, deployment, resource creation and migration, post-deployment testing, and maintenance. Each of these phases should be clearly indicated in the project document with an outline of what events each phase will include. Each phase outline should also include some rough dating for expected completion.

One phase that typically doesn't appear in the project document is the one that you may be in right now: the Discovery phase. This may appear in a different organizational document—perhaps one intended to track activity in the Information Technology department. The Discovery phase is essentially the development of the Goals and Purposes phases. A formal description of it might be a feasibility study in which you attempt to determine if a cluster of Hyper-V Servers is the right solution for your organization. Use the Discovery phase to address the problem of, "We don't know what we don't know."

To start, at least skim through the other chapters of this book and familiarize yourself with the concepts. It is highly recommended that you obtain a copy of Hyper-V Server or a trial of Windows Server and install and cluster it on a group of test computers. Look to Internet sources and forums for ways that others are exploiting these technologies in their organizations. Ask questions. Watch for any issues that others have had to determine if there are any pitfalls you need to be aware of before starting your own project. Don't restrict yourself to Hyper-V and Windows Server resources; forums and user groups for software you intend to virtualize can also be invaluable sources of insight.

With a project of this scale, it is rarely sufficient to declare that the project has been successful based on any single factor. Use the project document to list the events that must occur in order for the project to be considered a success. It is advisable to break these up into Critical and Desirable groups. Normally, a project is not considered to be successfully completed when all items marked Critical have been satisfied, but when unfulfilled Desirable items do not impede progress.

Success metrics should be very specific in nature. Don't simply use entries like, "High availability is functional." Instead, use entries such as, "All virtual machines can be Live Migrated from Host 1 to Host 2". Also, define metrics that cover all aspects of the installation. Use things such as, "Can transfer ownership of all Cluster Shared Volumes from Host 2 to Host 4". Depending upon your organizational needs and processes, it is acceptable to use a shorter list of generic success metrics on your official document that refer to a more specific set of metrics kept separately.

If at all possible, you should know as early as possible what sort of computing resources will be required by the applications that you'll be placing in your cluster. How well you need to plan for this depends somewhat on the resources you have available. If you have the financial and technical resources available to add new nodes on demand, you can quickly scale a Hyper-V Server cluster out to handle new or unforeseen demands. In all other cases, proper advance planning can ensure that you don't underpower or overpower your systems.

If you're going to be virtualizing an existing physical workload or converting from another hypervisor deployment, you can gather performance metrics to help you determine how to build out your new systems. Chapter 8, Performance Testing and Load Balancing covers how to track performance for your cluster, and the same concepts and techniques can be applied to standalone computing systems. The most useful information will be around CPU consumption, memory usage, disk space, and disk IOPS (input/output per second). While it is tempting to just add all current dedicated resources (such as CPU counts and total RAM usage), these numbers are almost always artificially high because few computer systems fully utilize their hardware resources. Also keep in mind that if you will be relocating some systems from older hardware, advances in technology may require fewer resources to provide comparable performance. Track resource utilization over a period of time that includes a typical workload. Of course, since you are using virtual machines, you'll have the ability to add or remove CPU and memory resources and expand disk space with very little impact, so mis-provisioning is usually not a serious risk.

If your new cluster will include a new software deployment for which you have no existing implementation and therefore you cannot track live performance metrics, consult with the software vendor. Keep in mind that it is normal for software vendors to overestimate the actual amount of hardware that their systems require, but they may not support their applications on anything less.

As you and other stakeholders learn more about the technologies and how they can apply to your environment, your goals and purposes will no doubt be expanded. Set a definite end point at which changes to the project's scope will no longer be accepted. Otherwise, you'll run the risk of scope creep, in which a project continually grows until it is no longer manageable. If further changes are desired but not required for the success of the project, they can be placed into a separate project to be completed after successful completion of the current endeavor. If you have no official guidelines, a logical point at which to cease allowing project changes is at the halfway mark of the time allotted to the Design phase.