Implementing Virtualization in the Small Environment

What Is the Technology Behind Virtualization?

Virtualization. Even if you're not technology savvy, you've likely heard of its concepts and perhaps even a few of its products. Virtualization's technology is a big and obvious play in enterprise environments. Its promise of shrinking your data center footprint, reducing power and cooling costs, and enhancing the workflow of your business make it a perfect fit for environments of size.

But small businesses and small environments needn't necessarily be left out in the cold. These oft‐overlooked places—where no‐ or low‐cost technologies are a necessity and administrators must take broad responsibility rather than specialize—stand to gain as well. Yet with so much information in the market today, much of which is focused on the needs of large environments, small businesses and their computing needs have a hard time understanding virtualization's technology, let alone justifying a move to it.

Thus the reason for this guide. This goal of this guide is to illuminate the technologies, the cost savings, and the workflow improvements that small businesses and environments will see with virtualization. By asking and answering a series of four important questions, this guide will pull you through the four most critical hurdles that you must understand to be successful in your virtualization implementation.

As the individual in charge of your company's technology decisions, you have probably asked yourself these same four questions:

• What is the technology behind virtualization? With the media's level of hype surrounding virtualization, an uninformed person could think it would solve every IT problem. Obviously this isn't true, but what exactly is virtualization and what can it do? Chapter 1 of this guide will discuss those technologies and what virtualization is really all about.
• What business benefits will I recognize from implementing virtualization? Understanding this technology is great, but the technology must provide a direct benefit to the small business to be of value. Chapter 2 of this guide will discuss the hard and soft benefits that small businesses and environments can immediately see by virtualizing servers.
• What do I need to get started with virtualization? Following an understanding of virtualization's benefits, small businesses next want to know how to get started. Virtualization comes in many no‐cost and for‐cost flavors, and can be implemented in innumerable configurations. Chapter 3 will discuss common first steps for small environments as well as the trigger points for investing in its no‐cost solutions.
• What are the best practices in implementing small environment virtualization? Virtualization is no longer a nascent technology. Having been available for many years, a common set of best practices for its implementation have been developed. Following these best practices will ensure that your implementation provides the greatest value to your business.

A Product­Neutral Approach

There are many virtualization products available on the market today, each with its set of benefits and detractors, features and gotchas. With this reality in mind, this guide will take a product‐neutral approach to presenting the technologies associated with virtualization. The goal with this guide is to empower you with the information you need to make smart decisions about how to improve your computing efficiency with virtualization technology.

What Is Virtualization?

Circling around today's IT conversations, the question is really no longer "Should I virtualize my servers?" but "When can I do it?" Although systems virtualization has technically been around since 1967 with its start in IBM mainframes, its incorporation into Intel x86 systems started in the late 1990s. Since that time, virtualization has matured quickly over a few short years to become a major component both in the server room as well as on individual desktops.

As such, virtualization is not new technology. Although some vendors have recently introduced new products that fit under virtualization's banner, this technology has been around for a long time. Because of this long history, virtualization and its products today are mature solutions that are trusted by enterprises worldwide. That trust extends to even the most critical of server workloads.

Layers of Abstraction

At its most basic, virtualization is involved with the abstraction of computer resources. This abstraction is put into place because it enables a logical separation between a resource and how that resource is used. Consider the address book on your telephone. This address book provides an excellent example of how a layer of abstraction works. When you enter a name into that address book, you assign it a telephone number. You do so because it is operationally easier to work with a person's name than their individual phone number. Abstracting that person's number beneath their name makes it easier and more efficient to work with the telephone system.

Another benefit of abstraction is the ability to relocate an underlying resource without affecting how you access it at the top level. With your telephone address book, it is possible to change a person's underlying phone number without changing their name. As a result, a change to that person's phone number doesn't have to change your process for calling them.

With virtualization, this abstraction exists between two "layers" of a computer system. There are many virtualization architectures available today, with the differences in each having to do with where that layer is positioned. This guide will discuss the kind of virtualization commonly called hardware virtualization or systems virtualization. In this type of virtualization, everything that makes up a computer's operating system (OS), installed applications, and data are abstracted away from its physical hardware to create a "virtual" server. Figure 1.1 shows an example of how this setup looks in comparison to the earlier phone number example.

Figure 1.1: Virtualization involves adding layers of abstractions to resources.

The Hypervisor

For virtualized computers, that layer of abstraction is handled through the use of a hypervisor. This hypervisor is a thin layer of code that is installed directly on top of a server's physical hardware. "Below" itself, the hypervisor's code interfaces with the hardware devices that make up the physical server. At the same time, the hypervisor presents a uniform interface "above" itself, upon which virtual machines can be installed. The job of the hypervisor is to intercept hardware resource requests from residing virtual machines and translate those requests into something understandable by the physical hardware. The reverse holds true as well: Requests from physical hardware that are destined for a virtual machine are translated by the hypervisor to an emulated device driver the virtual machine can understand.

As you can see in Figure 1.2, no matter what hardware composition is present on the physical machine, each residing virtual server sees the same set of emulated hardware because they are exposed "on top" of the hypervisor.

Figure 1.2: The hypervisor abstracts each server's unique hardware to create a uniform platform for virtual servers.

The benefit of this abstraction is that the computer's OS and applications no longer directly rely on a specific set of physical hardware. A virtual machine can be run atop essentially any physical hardware, effectively decoupling hardware from software. If a piece of physical hardware experiences a problem, the processing of that server instance can be manually or automatically relocated to different hardware. If Brand A of a server is no longer available for purchase or parts, it is now trivial to relocate the virtual machine to Brand B. In every case, this movement requires no configuration change to the virtual machine itself.

Hardware Independence with Virtual Servers

This introduction of hypervisors into the traditional data center enables levels of systems commonality never before seen by IT. Whereas physical servers are often quite different from each other in terms of device and hardware composition, virtual servers operate with functionally the same hardware. When every server in your environment runs with the same hardware, you have fewer drivers to deal with, fewer conflicts to plan for, and a much more predictable environment to administer.

A result of this commonality is greater flexibility with the positioning of server instances. Consider the situation in which a critical server experiences a problem. In the worst of cases, it can be necessary to relocate that server's OS and applications to a new piece of hardware. You might want to do so because the service that server is running is highly critical to your business, and its extended downtime costs you money.

If that server is a physical server, this task is exceptionally complex and is generally possible when the two servers have the exact same hardware. This requirement presents a problem because many environments use servers from multiple vendors or product generations, and keeping exact spares on‐hand to support this need is expensive and wasteful. As a result, a server's hardware problem can directly impact the functionality of your critical business services.

With virtual servers, a hardware problem isn't really a problem at all. Because virtual servers are decoupled from their physical hosts, they tend to see a greater level of inherent resiliency. Should a virtual server's host experience a problem, moving the virtual server to a new host involves little more than a file copy. This process can be invoked by an administrator when the problem occurs, or in some cases, can occur automatically when virtual monitoring software recognizes the problem. In either case, the hypervisor ensures that a uniform platform exists for virtual machines no matter what kind of server to which it is installed.

Virtualization Reduces Your Hardware Footprint

Virtual machines are also superior to physical machines because more than one virtual machine can run atop a single host. Because virtualization eliminates the direct connection between server instance and physical hardware, the hypervisor can support the running of multiple virtual machines atop a single host. This ability to consolidate multiple physical machines onto a single virtual host provides substantial cost savings while increasing the efficient use of existing hardware. In essence, with virtualization, you'll actually use more of your purchased server hardware.

Why is this true? As an average, many Windows server computers rarely use more than 5 to 7% of their available processor resources. They are often overloaded with RAM memory, sometimes containing 4×, 8×, or greater memory than is actually needed to process their assigned mission. This massive over‐engineering of computer hardware has been common in IT as the rate of server hardware performance—and subsequent reductions in cost—has outpaced the needs of software. It also happens due to the standardized hardware configurations that are available to be purchased through the major server vendors. As a result, many non‐virtualized servers today spend much of their time idly flipping ones and zeroes as they wait for their next instruction.

Yet with your small business, you likely want to get the most out of those costly server purchases. With virtualization, another major job of the hypervisor is to schedule hardware resource requests between virtual machines on the same host. Thus, a large number of underutilized physical computers can be easily consolidated onto a single virtual host and run concurrently.

The result is that the number of physical servers you need to run your business goes down significantly. This reduction in your total number of physical servers means less equipment to manage, to power, and to keep cool, all of which directly reduces your overall costs. Figure 1.3 shows a representative example of how this reduction might change the look of your server racks.

Figure 1.3: Virtualization consolidates many underutilized physical machines onto a single virtual host.

Virtual Consolidation Requires Performance Management

Obviously, with the consolidation of many server instances onto fewer physical servers, there is the potential to simply go too far. When too many virtual machines are collocated on the same host, each finds itself fighting for needed resources. The result is that the performance of every virtual machine goes down.

One critical skill that gains priority in virtualized environments is the monitoring and management of host and virtual server performance. Your virtual platform software should include the necessary tools to allow you to watch for and correct performance‐related problems. This guide will talk more about best practices for performance management in Chapter 4.

Virtual Disks Enjoy Special Benefits

One mechanism that enables this flexibility with virtual servers is in the way their hard disks are presented. Inside a traditional physical server's hard disk are stored the thousands of files and folders required for that server instance. Those thousands of files and folders are responsible for the OS, any installed applications, and even the data that the server works with in fulfilling its mission.

The OS that makes up a virtual server still requires each of those files to be available, and from the perspective of the virtual server itself, those files are individually accessible. However, from the perspective of the virtual host, all the files and folders on that server's disk drive are encapsulated into a single file. This single file—typically one per disk volume—bestows unique capabilities on the virtual server:

• File relocation. Since the entire composition of a virtual machine is encapsulated into a single disk file, relocating a server from one host to another requires little more than moving that file to a new host. Virtual platforms often have a small handful of additional files that store configuration information about the virtual machine itself. Yet every file and folder that makes up that server is effectively encapsulated into that single disk file per mounted volume.
• File copy replication. Making the previous feature even more useful is the ability to copy that single file to create a new one. Completing this process creates an exact replica of the original server that can be hosted elsewhere in the environment. This capability makes it easy for administrators to create additional servers as necessary. Entire server template libraries can be created for commonly needed servers, drastically reducing the amount of time required to build new servers when needed.
• File snapshots. Today's modern file systems and virtualization platforms include the ability to "snapshot" the server's disk file as well. This snapshotting process effectively creates a second disk file that is connected to the first. When this process is initiated, all changes to the original disk file are instead written to the second disk file. The virtualization platform combines both the original and "delta" disk files to create and process the virtual server. The benefit here is that a snapshot of that virtual server's state can be created at any point. Changes made to that virtual server after the snapshot are stored in the delta file. If those changes are later no longer desired, the administrator simply "rolls back" the server to its pre‐snapshot state, eliminating the deltas. This feature enables administrators to protect a server's state from the installation of a poorly developed patch or application. It allows administrators the flexibility to work with a server knowing that any changes can be immediately rolled back if mistakes are made or can be merged with the server's "main" disk file if successful.
• Single­file backup and guaranteed restore. Traditional backups with physical servers have historically been an area of concern with IT administrators. With thousands of files that make up a typical Windows server, the loss of only a single file in a regular backup can prevent the successful emergency restore of that server. Making this problem worse, backup software can sometimes miss files because they are locked or in use. The combination of these two problems makes the successful restore of a failed server a less‐than‐guaranteed situation. With virtual servers, however, backing up the entire server requires backing up only its single disk file. This encapsulation of a server's state onto a single disk file goes far towards ensuring its successful restore.
• Inexpensive disaster recovery. Lastly, small environment disaster recovery has historically been impossible due to the operational costs and complexities of managing a secondary off‐site data center containing duplicate servers and other hardware. Virtual servers and their disk files bring inexpensive and operationally feasible disaster recovery to even the smallest of businesses. Necessary is the offsite replication of backed up virtual server disk files. Also needed at that backup site are a set of servers that can later power on those virtual servers after a disaster. Because of the impact of the hypervisor, those servers needn't be the exact same hardware as what is installed at your primary site.

Virtualization Enables Cost‐Effective Role Isolation

A common architectural decision in many of the smallest environments is to operate numerous server roles atop a single server. These services can be infrastructure services such as DNS, DHCP, or Active Directory (AD) domain services, or in some cases, can be user services such as SQL, application services, or email servers like Microsoft Exchange.

This assignment of multiple roles per server is actually in conflict with the best practices for Windows server architecture design. Best practices suggest that each server role or application should be installed to its own individual server. The reasons for this role isolation are many:

• Isolated roles are less likely to conflict with each other
• The loss of one server will not negatively impact the processing of other services
• Patching, update, and administrative requirements grow less complex when roles are isolated
• Lowered complexity means a reduction in the chance for an outage

The problem is that small businesses and environments are often forced into multiple roles per server because of limited funding. Many small businesses simply cannot afford the costs associated with purchasing individual servers for each needed service. This situation is especially problematic when considering the low resource‐utilization nature of many infrastructure services. Although role isolation is a good idea, most infrastructure services use very little of a server's processing power, making their consolidation appear to make more sense for the small environment.

Figure 1.4: On the left is a physical server with consolidated roles. The right shows the same server as a virtual host supporting role isolation.

Figure 1.4 shows how the addition of virtualization often changes the outcome of this decision. Incorporating virtualization into the small environment offers an opportunity to address this conundrum, due to two major factors:

• Low­use infrastructure services tend to be excellent candidates for virtualization. Infrastructure services such as those discussed earlier tend to require very few resources in order to accomplish their stated missions. For example, in very small domains, AD domain services requires very little processor power and can be operated atop a server configured with as little as one gigabyte of RAM. This level of service consumes only a slight percentage of a server's total available resources. As such, virtualizing multiple critical but low‐needs services such as these provides a way to efficiently isolate each into its own virtual server.
• Special virtualization licensing from Microsoft extends the value of each physical license. With the release of Windows Server 2003 R2 in 2005, Microsoft updated the terms of its licensing agreements. These new terms added licensing benefits for certain editions of its server OS. Specifically, a company is entitled to install and license an additional four virtual instances for every purchased license of Windows Server 2003 R2 Enterprise Edition. For Windows Server 2003 R2 Datacenter Edition, an unlimited number of additional virtual instances can be installed and licensed. This count of additional licenses is related to concurrently running instances, giving a business the option to install—but not run—an unlimited number of non‐running instances. With the release of Windows Server 2008, Microsoft changed the terms again to allow one additional virtual instance when purchasing Windows Server 2008 Standard Edition.

The combination of a virtualization's consolidation capabilities with Microsoft's licensing benefits now enables even small businesses to build the right level of role isolation into their networks. By building role isolation per best practices, small businesses and environments can further enhance the resiliency of their servers and services.

P2V Converts Physical Servers to Virtual Servers

All of this discussion about moving to virtualization is incomplete without a nod to the tools that enable the direct conversion of physical servers to virtual ones. Moving your environment from physical to virtual needn't require the wholesale reinstallation and rebuild of every server in your environment. Rather, all virtualization platform software typically includes a set of tools that convert physical servers to virtual servers. These tools are generically referred to as P2V Tools.

This P2V process is very similar to the processes used to image and rapidly deploy desktops and laptops. Where it differs is in the end result. Instead of rapidly deploying an image to a new piece of physical hardware, the result of a P2V conversion is the creation of a virtual server's disk file. The P2V process is also different in that its processes automatically inject the proper device driver software into the imaged virtual server. This injection is required so that the server can correctly interoperate with the virtual platform and its hypervisor. These tools are particularly useful in that they can convert physical servers without requiring them to be powered down. Most P2V software available today can complete a full conversion while the source machine remains online and operational.

In the past, early P2V software was quite different in the types of capabilities and feature sets available. However, today's P2V software has become a relative commodity between vendors. As such, the capabilities between the P2V software of one virtualization platform vendor and another are fairly similar. This being said, there remain two areas in which differences remain. The first has to do with the administrative activities that wrap around the P2V process. These relate to scheduling of the P2V process, P2V agent distribution, the automatic mounting of converted servers into the virtualization environment, and scripting exposure for custom actions.

Motioning Automates Load Balancing & Failover

Earlier, this chapter discussed how small businesses and environments—just like large enterprises—cannot function if their services are not up and operational. Lacking those services, even the small business stands to lose money, as they cannot meet the needs of their customers. To that end, it was also discussed how virtualization enables a virtual server to be relocated from one host to another in the case of a host problem.

The generic industry term for the automated move of virtual machines from one host to another is motioning. There are three common ways in which motioning can occur with a virtual machine:

• This process can be invoked by an administrator to relocate virtual servers off a potentially failing host.
• It can be invoked to move running virtual machines off of a host prior to an upgrade that involves downtime on that host.
• It can automatically relocate and restart all virtual machines onto new hosts after a complete host failure.
• It can be used as a performance management tool to load‐balance virtual servers across available physical hosts to ensure the best possible performance.

Different virtualization platforms enable motioning through different mechanisms, and each requires its own set of technologies for this automated relocation to take place. Essentially, all virtual platforms can relocate a virtual server through a traditional file copy when that server is powered off. However, some provide the ability to relocate that virtual server while it remains powered on. This process is often generically referred to as live migration, and it requires a bit more additional technology involvement than what is required for a traditional file copy. Let's take a look at the components that are commonly required in order to enable this added reliability for your virtual servers:

• Supporting virtual platform. First and foremost, your virtual platform must support the live migration capability. Important to note here is that the features necessary for accomplishing a live migration often require an add‐on cost to the base cost of the virtual platform.
• Flexible networking. Your networking infrastructure must support the correct configuration and features necessary to recognize a server has been moved from one network port to another and to quickly re‐converge. The networking protocols necessary to enable this automated reconfiguration work with the virtual platform to handle the change and are often a feature available only in business‐class networking devices.
• Shared storage. Lastly, some form of shared storage is usually required for the storage of virtual machines. This requirement is commonly fulfilled through the use of shared storage such as iSCSI, fibre‐channel, NFS, and others, all of which have the necessary capabilities to support multiple, simultaneous host access. Although the relocation of a virtual server while it is powered off usually involves moving its disk files as well, most live migration technologies only relocate the processing of the virtual machine. The virtual machine's disk files do not actually move during the relocation. Figure 1.5 shows a graphical example of how this process works. You'll see in this figure how the processing of the virtual machine changes hosts but the virtual machine's disk files do not.

Figure 1.5: With live migration, when a host is failing or load needs rebalancing, virtual machine processing can be automatically relocated to a new host without server downtime.

Live Migration with Storage Relocation

Although most live migration technologies do not relocate server disk files during a migration, some virtualization platforms are beginning to include this as a feature. This dual migration of server processing and disk file relocation can be a boon for environments that want to maintain the uptime of their servers while moving their disk files to new locations.

High‐end motioning technologies all involve add‐on costs to virtualization environments, yet they enable the highest levels of resiliency and load balancing for your virtual servers. Thus, using them in your environment will involve a tradeoff of cost versus capabilities.

When considering a virtualization solution, factor in your business' tolerance for downtime. Due to the nature of their business, some small environments can tolerate the loss of even a critical server for a few hours up to a day or more. Others cannot tolerate downtime for even a few minutes.

What Will This Technology Cost?

It can cost as much as…nothing. Virtualization platforms exist today with prices that range from freeware to very expensive. The key differences between platforms are in the type and scalability of features that layer on top of the basic capabilities outlined in this chapter.

The basic ability to install a hypervisor to a virtual host and begin running virtual machines is today considered a commodity technology from the perspective of price. Essentially, every virtualization software vendor today provides the basic capability to run virtual servers atop a hypervisor for no cost. Other no‐cost features include:

• The ability to remotely access the virtual server's console over the network
• The ability to enact machine‐level changes to that machine, such as power on, power off, reboot, and others
• The ability to perform basic snapshotting
• The ability to perform basic virtual server backup and restore of entire virtual servers at once

These capabilities enable small businesses and environments with light needs to quickly move to virtualization with very little or no initial capital investment. For the needs of many small businesses and environments, these capabilities available with virtualization's free software options will suffice. What are missing from these free tools, however, are the additional management functionality and high‐end features that may be a necessity down the road.

It's More Than Just Software

It is important to note that with the more robust classes of virtualization software, there are more costs to the organization than just the software itself. When an organization decides that it needs more advanced capabilities, additional hardware such as servers, storage, networking, and cabling will likely be necessary as well. This additional hardware can substantially increase the cost associated with making the jump to high‐end virtualization. That being said, substantial additional benefits are gained with those additional costs.

Will My Existing Servers Be Supported?

In all likelihood, yes. It is true that many virtualization platforms require the use of recent hardware features on servers that support virtualization extensions directly on the hardware itself. However, not all virtualization platforms have these requirements. Many no‐cost virtualization solutions can be run atop essentially any server available today.

It is, however, important to temper the previous statement with a caution. Virtualization is all about performance. As such, the specified hardware requirements that are necessitated by many high‐end virtualization solutions are in place to ensure the highest level of performance. From a technical perspective, virtualization solutions of the type focused on in this guide can be broken down into two major classes:

• Type­1. Type‐1 virtualization solutions as a whole are the most equivalent to what has been discussed in this chapter so far. These solutions leverage a hypervisor that itself is installed directly atop physical hardware. Type‐1 virtualization solutions can and often do require specialized hardware, yet they enjoy the highest levels of performance. This is due to the hypervisor's extremely "thin" code as well as its positioning directly between virtual servers and hardware.
• Type­2. Type‐2 virtualization solutions actually install as applications on top of an existing OS. These solutions leverage the existing OS and its integrations into hardware resources. The hypervisor for these types of virtualization solutions is functionally equivalent to what has been discussed in this chapter thus far. However, because of the added OS "layer" beneath the hypervisor, these solutions suffer from lowered levels of performance.

Your existing servers—even those that are beyond their operational life cycle—are very likely to support Type‐2 virtualization and its products. Your more recently purchased servers are likely to support both classes. Obviously, with Type‐1 virtualization's dramatic performance enhancements, it is a likely goal for use in your small environment today.

Telling Them Apart

In every case, a Type‐1 virtualization solution will involve the direct installation of a hypervisor to a host system. That host system can include an OS for management purposes or can be devoid of a full OS entirely. In every case, a Type‐2 virtualization solution will arrive as an application that is installed on top of an existing OS instance.

Virtualization Makes Sense for Even the Smallest of Environments

Virtualization makes sense for large enterprises. In an all‐physical world, their massive environments are so wasteful of processor cycles as well as power and cooling energy that any consolidation of servers to virtual servers makes sense.

But virtualization makes sense for the small environment too. Small environments stand to gain reliability advantages from virtualization's enhanced systems commonality. The ability to relocate virtual servers when hardware failures occur is a boon to availability for small environments. The accident protections gained through snapshots reduce downtime that is related to administrator mistakes. Tying all of these together are the cost savings gained through consolidating many servers onto few.

It is the goal of this guide to assist you with understanding the nuances of how virtualization can work in your small business or environment. To continue this discussion, the next three chapters will expand the conversation to include the benefits, implementation suggestions, and best practices you can employ today to incorporate virtualization into your business and technology plans.

What Business Benefits Will I Recognize from Implementing Virtualization?

Small businesses and environments are indeed small due in many ways to their limited budgets. As such, the small business must leverage no‐cost and low‐cost tools wherever possible if they are to survive. They must be extremely careful about where they spend their money, making sure that every investment provides a direct and recognizable benefit back to the bottom line.

This focus is much different than what is typically seen in large enterprises. With large organizations, benefits are more easily classified in terms of operational efficiencies, with reductions in time and increases in agility directly equating to reductions in cost. Enabling improvements to manageability are a key concern when you have 1000 servers in your data center because their management involves a lot of time and cost. The small business, however, must look to whole dollar or "hard" cost savings when considering any cost outlay.

To that end, answering the question posed by this chapter requires a primary focus on hard dollar savings to be of benefit to the small environment. You'll see just that focus in this chapter. Yet at the same time, this chapter will also discuss some of those other "soft" benefits that make sense. You might be surprised that even in the small environment, the addition of a "soft" benefit can in the end result in a recognizable "hard" return.

Why Should My Budget Care About Virtualization?

As with many IT technologies, virtualization's first play into the IT market was targeted directly towards the needs and demands of the enterprise organization. For enterprises, virtualization is an obvious and smart investment. The cost savings of reducing 1000 servers to 100 are easy to see. A 90% reduction in total server count, along with their power and cooling costs and all the associated administration improvements, makes a lot of sense for the very large environment.

Yet small environments can also benefit through the technologies first employed by the large corporations. For the small business environment, that same 90% reduction in physical servers may not reduce 1000 to 100, but reducing 20 to 2 results in just as striking a benefit to your cost basis. Those benefits obviously relate to your bottom line; at the same time, they go far in improving your business' computing agility.

With this idea in mind, why should your budget care about virtualization? What are the benefits your small business or environment stands to realize from a virtualization rollout? Let's first look at a few high‐level areas of return you can expect. With your virtualization investment

• You will save money on hardware and software
• You will save money on power and cooling
• Your entry costs will start low.
• You will leverage your existing infrastructure
• Yu will recognize improvements to your business services
• Your administrators are likely already familiar with this technology

All of these are pretty lofty statements. Yet each brings about a benefit to the business through direct cost avoidance, reduction in operational expense, or elimination/reduction of risk. For a more detailed analysis, let's take a look at each in detail.

You Will Save Money on Hardware and Software

Virtualization's savings on physical hardware tends to arrive first with the need for future expansion. In the physical world, adding two additional servers to support a new business venture or management activity requires purchasing two new pieces of hardware, along with the necessary software and OS licenses, maintenance, and shipping costs associated with those servers. Additional manpower costs are required to provision those servers, install their OS, add applications, and generally prepare them for use.

In a virtualized environment, the infrastructure for servers is abstracted away from the traditional 1:1 relationship between server chassis and new business service. With a properly planned and managed virtual infrastructure, your environment will be configured to reserve sufficient processing power to support expansion. Thus, a need for two new servers does not require a requisition for two new physical servers. Fulfilling that need instead involves little more than provisioning them within the virtualization platform's management console. Although the manpower costs associated with application installations are generally the same, the other provisioning tasks—such as unboxing, mounting, cabling, and even the OS installation—are eliminated. Figure 2.1 shows a bar graph that illustrates these costs.

Figure 2.1: Adding a new virtual machine to a virtual host eliminates many costs traditionally associated with adding new services.

In Figure 2.1, you can easily see how the majority of the costs associated with bringing a new service online relate to its physical hardware. Buying new servers involves the cost for those servers as well as maintenance and shipping fees. That new server also incurs a marginal cost associated with getting it installed into your infrastructure. Racks, cabling, power and cooling, network connectivity and its associated infrastructure, and in some cases, shared storage are all potentially hidden costs that might not be accounted in the plans of many small businesses and environments. In short, there are quite a few more costs associated with running a physical server than just the server itself.

This is the situation displayed on the left of Figure 2.1. Now, contrast this situation with the virtual host shown on the right. There, the costs associated with purchasing the server, adding maintenance and shipping fees, and provisioning are all grayed out. This is the case because these components of these marginal costs are effectively zero. Adding that new virtual server to an existing virtual infrastructure requires no physical reconfiguration and involves no additional hardware purchases.

The Laws of Physics Still Apply

There is an important caveat here: The costs identified are valid when your virtualization infrastructure has the residual capacity to support a new virtual server. As with everything else, virtual platforms must still obey the laws of physics. Any virtual platform will have a fixed amount of resources available to distribute to virtual machines based on the host's configured hardware resources. It then follows that at some point additional hosts— with all their associated costs—will be needed to support your future expansion.

Yet adding that new host is uniquely different. A new virtual host can support more than one virtual machine. Thus, depending on the resource needs of your virtual machines, adding a new virtual host is like getting many more than one new server for the price of one.

You should notice in Figure 2.1 that the costs associated with OS licensing are specially highlighted for the virtual host. This is due to the special virtual machine licensing benefits that are offered by some OS manufacturers. For example, Microsoft provides the following license benefit when using the Enterprise Edition of Windows Server 2008:

A Windows Server 2008 Enterprise license grants the right to run Windows Server 2008 Enterprise on one server in one physical [instance] and up to four simultaneous virtual [instances]. If you run all five permitted instances at the same time, the instance of the server software running in the physical [instance] may only be used to run hardware virtualization software, provide hardware virtualization services or to run software to manage and service the [instances] on the server. You may run instances of the Standard or prior versions in place of Windows Server 2008 Enterprise in any of the [instances] on the licensed server

Microsoft's rules for the Datacenter Edition of Windows Server 2008 provide an even greater benefit:

When Windows Server 2008 Datacenter is licensed for every physical processor in a server, the server may run the server software in the physical [instance] and an unlimited number of virtual [instances] on the licensed server. You may run instances of Windows Server 2008 Standard or Windows Server 2008 Enterprise in place of any Windows Server 2008 Datacenter in any of the OSEs on the licensed server. Unlike with Standard and Enterprise, with Windows Server 2008 Datacenter, the instance of the server software running in the physical [instance] may be used to run any software or application you have licensed. Because Windows Server 2008 Datacenter permits an unlimited number of simultaneous running instances on a licensed server, you have the flexibility to run instances of Windows Server in virtual [instance] without having to track the number of instances running or worry about being under‐licensed.

In effect, the move to virtualization immediately increases your license count for certain OS versions by 4× or more. This benefit automatically expands your capacity for OS and virtual machine growth.

Application Licensing Is Not Necessarily Straightforward

Be warned that although licensing for Microsoft OSs gains benefits, licensing for your applications can grow complex based on the specific language of the licensing terms. When installing applications to virtual machines, pay special attention to license language that focuses on processor‐based licenses or server‐linked licenses. These can have unexpected impacts on installations to virtual environments.

Even if your goal is to consolidate just a few servers to a single host, your reduction in total server count frees those physical server chassis for new missions. As a result, the incremental cost of adding new services to your business drops dramatically. When the addition of a new service no longer automatically also requires a new server, you can quickly and inexpensively expand your business as you see fit. In the case of a large expansion, the cost savings alone in new computer hardware can often pay for a virtualization implementation's initial costs right up front.

Figure 2.2: With virtualization's server consolidation capabilities, each new server purchase nets more than one virtual server instance, multiplying the benefits associated with its cost.

You Will Save Money on Power and Cooling

Hardware and software costs are not the only hard return gained by the organization that makes the move to virtualization. Costs associated with powering and cooling that server can similarly be avoided at a rate that is directly related to your level of consolidation.

It is perhaps easiest to see this by looking at some real numbers. To give you an idea of the amount of money you are currently spending on merely powering your current servers, consider the following example. According to the power consumption calculator found at http://h30099.www3.hp.com/configurator/powercalcs.asp, the following server configuration consumes approximately 300 watts of energy at steady state and when processing at a minimum 10% utilization:

• HP DL385 Generation 5 server‐class hardware
• 115V power
• 2.7Ghz Processor
• 8GB RAM
• A single PCI‐E card
• Five 146GB SAS hard drives

As servers are generally operated continuously throughout their lifetime, this server's 300W of energy are required for 24 hours a day. If your average energy cost is 15¢ per kWh, each server of this type will cost you $395/year to power. Twenty of these servers will cost you $7900/year for power alone.

The costs don't stop there. As a rule of thumb, every watt consumed for a server's processing generates one watt of heat. Removing that heat requires air conditioning, a process that involves additional power. In general, every watt of heat requires another watt of energy to cool. Thus, for an environment that has perfect air conditioning—one that runs at 100% efficiency—you can assume that cooling your servers effectively doubles the costs.

Thus, as Figure 2.3 shows, to power and cool 20 servers of this type will require a recurring cost of $15,800/year.

Figure 2.3: 20 example physical servers can cost $15,800 per year to power and cool.

These costs can be even higher if you house your server infrastructure within an offsite hosting facility. To recognize profit, these facilities up‐charge the costs for power and cooling while also charging for the space consumed by the server chassis itself.

As a result, there are dramatic hard cost benefits that can be gained through the consolidation of server instances onto fewer server chassis. This chapter has already discussed how the goal of achieving a 90% consolidation of servers results in a reduction from 20 to a mere 2 servers. This directly reduces your overall power and cooling costs by $14,220 per year. Considering the average cost of server‐class equipment required to support virtualization, the savings in power and cooling costs alone could buy an additional server each and every year to expand your existing virtual machine capacity.

Your Entry Costs Will Start Low

You may at this point be asking, "For all these great cost‐savings benefits, what will I have to pay to start?" This is an honest question, because at first blush, some virtualization platform software can appear expensive. However, that expected initial expense needn't necessarily be high for small businesses and environments who consider the right approach to getting started.

For a small implementation, your initial cost outlay for a move to virtualization is likely to include some or all of the following components:

• Virtualization platform software. Most virtualization vendors provide an entrylevel software edition at no cost that includes the basic features. Although there tends to be a standard set of features available across all no‐cost solutions, there are notable differences between virtualization vendors. The next section will discuss some of the specific features you can expect to get from most solutions, but research your options thoroughly before deciding on a solution.
• Maintenance and support. Although the initial software acquisition for entry‐level virtualization software involves no cost, the maintenance and technical support for that software will incur a minor cost per year. This maintenance and technical support is critically helpful to ensure that specialists are available in the case of an emergency. Virtualization effectively encapsulates the whole of entire business processing within its platform, so smart businesses should always consider the purchase of a minimum technical support contract as a risk‐reduction measure.
• One or more physical servers. You will require one or more physical servers on which to install the virtualization software. Host resources are a primary indicator of the resulting level of performance once servers are virtualized, so these servers should be equipped as powerfully as you can afford. Additionally, the function of these servers should be reserved exclusively for supporting the virtualization environment. Due to the high‐resource utilization seen on virtual hosts, it is not a recommended practice to leverage multiple roles for a virtual host.
• Additional RAM memory. Virtualization is heavily dependent on RAM, with more memory always preferred over less. More memory in a virtual host means that host can support more collocated virtual machines. With the cost of memory relatively inexpensive, this hardware upgrade quickly pays for itself by increasing your consolidation capabilities.
• Additional storage. Each collocated virtual machine requires virtual host disk storage that is equivalent to the real amount of disk storage that is configured for the virtual machine. Thus, if you want to collocate 10 virtual machines onto a single host and each virtual machine has a 40G hard drive, you can need 400G or more of storage to support this configuration. Be aware that some virtualization software technology requires real disk space for only the consumed portions of virtual disks rather than the entire assigned virtual disk. This technology can reduce your overall disk space requirements but must be closely monitored to prevent host disk space from being fully consumed.
• (Optional) External, shared storage. Direct‐attached storage within a physical host is limited by the count and size of disks that can be installed to the server chassis. Thus, the capabilities of a physical server will eventually be bound by its disk space. External storage that is shared between multiple hosts and connected via fibre channel, iSCSI, or NFS tends to incorporate a greater expansion capability and to enjoy more high‐availability features. This type of external storage is also a primary requirement for the advanced "motioning" capabilities discussed in the previous chapter.

Chapter 3 will go into more detail associated with the physical and logical elements you will need to get started with virtualization. However, the previous list is useful for helping you understand the cost impacts of those components. Discounting the last bullet—which can be an expensive addition—each of these components can be incorporated at very little cost.

With this information in mind, there are a number of architectural decisions that you will need to consider when planning your virtualization implementation. Those decisions relate to the features you anticipate needing, as well as understanding where additional costs can be applied to improve your performance, reliability, and overall management experience. Consider the following decisions and cost impacts when planning your virtualization implementation.

Conscious of the Functions You Need and Don't Need

Entry‐level and no‐cost virtualization platforms focus primarily on basic server partitioning. This basic server partitioning embodies the technologies necessary to consolidate multiple virtual servers onto one physical host. With this basic server partitioning comes the core abilities to work with those machines as if they were physical computers. Your entry‐level software platform will typically include the ability to

• Create virtual machines and run them concurrently atop a single virtual host
• Power on, power off, and suspend running virtual machines as well as adjust their physical configuration
• Interact with the console of a running virtual machine through some form of client interface
• Migrate virtual machines from one host to another while that virtual machine is powered off
• Support basic snapshotting functionality, enabling limited snapshotting and snapshot management of virtual machines
• Manage virtual machines and their hosts on a per‐host basis
• Monitor the current and immediate‐past performance of that virtual machine with a limited set of counters
• Support limited capabilities to adjust the power‐on and power‐off sequence for virtual machines after a host failure; this prevents the race condition where every virtual machine attempts to power on at once after a virtual host reboot
• Set and enforce limited roles and permissions for users who interact with virtual machines

For most small businesses and environments, these capabilities are enough to get started. The features in this list enable your environment to create, manage, and nominally interact with hosted virtual machines. However, there are additional capabilities that are gained with the movement from no‐cost to for‐cost virtualization tools. Although a discussion of specifics is best left for the next section, these capabilities focus on enhancing the management flexibility for running virtual machines as well as enabling them with highavailability features.

Aware of the Paths for Future Augmentation

The basic features highlighted earlier are effective for small businesses, especially when considered alongside their entry cost. Yet it is important to recognize that the move to virtualization very quickly consolidates a lot of resources onto a small number of physical devices. As such, the loss of a single virtual host can be catastrophic if preparations are not made.

This need for business continuity in the case of a virtual host failure is a primary motivator for many small businesses to eventually jump to for‐cost tools. Among other features, the add‐on capabilities enabled by for‐cost tools are focused on preventing this catastrophic loss of business processing. Consider the following as features that you can expect to see upon the upgrade to a for‐cost virtualization platform:

• Live migration capabilities that allow running virtual machines to be moved to an alternate host before a host failure
• Automated relocation to new hardware and restart of virtual machines immediately upon a host failure
• Load‐balancing calculations that manually or automatically re‐balance running virtual machines across hosts to prevent resource contention
• Disk storage migration that enables the zero‐impact relocation of virtual machine disk files to alternate storage
• Integrated block‐level backup capability for virtual machines, enabling the singlefile backup of an entire virtual machine as well as guaranteed restore; some for‐cost virtual platforms additionally offer the ability to perform individual file restores from an image‐level backup—this feature is useful in speeding the recovery of individual files
• Automated replication features that copy backed up virtual machines to alternate locations for disaster recovery purposes
• Centralized management, enabling the administration of all components of the virtual environment as a single unit

All businesses grow, as do their computing requirements. The smart business will look for virtualization platforms that provide an easy migration path from early no‐cost to later forcost software. As your business grows more reliant on your virtual infrastructure, it is likely that you will find these additional features necessary. Ensuring that your virtual platform can scale to meet your needs is critical for its long‐term viability.

Attentive to Hardware Requirements and Upgrades

In the end, keeping those virtual machines up and running is the most critical goal of any virtualization implementation. Yet the software that embodies its platform is only part of the expansion goals for a virtual infrastructure. The architecture of your computing environment itself must also scale to support your growing availability requirements.

These architecture enhancements arrive with the measured upgrade of your entire computing infrastructure. Although these capabilities may not be necessary as your business or environment starts small, growth over time will eventually lead the smart organization to making careful purchases. Your goal with hardware upgrades will be to reduce or eliminate single points of failure within your infrastructure, which ultimately increases the reliability of your business services themselves.

Figure 2.4: Additional hardware capabilities can be added to virtually every component of your virtual infrastructure to add resiliency.

To fully support high availability, the computing environment architecture can be expanded in many ways, some of which are called out in Figure 2.4:

• Adding network cards or entire paths ensures that the network is not a single point of failure
• Moving from local storage to shared storage decouples the data storage layer from the processing layer, adding flexibility and greater resiliency
• Storage appliances such as NAS and iSCSI tend to include internal designs that reduce or eliminate points of failure
• Even the apparently simplistic act of isolating storage network traffic from production network traffic prevents network conditions from impacting a virtual machine's access to its disks

These hardware augmentations needn't necessarily happen at once. Your small business or environment can incrementally add layers of redundancy as requirements and budget allow. Decisions regarding implementing these added layers will need to be made alongside your needs to expand your capacity for more virtual machines through the addition of new virtual hosts.

You Will Leverage Your Existing Infrastructure

Irrespective of what you want your environment to look like down the road, making the move to virtualization today requires technologies that you likely already have in place. Most no‐cost virtualization solutions today can run atop your existing infrastructure. Some virtual solutions require newer features such as 64‐bit hardware, hardware‐based data execution prevention, and/or hardware‐based virtualization extensions. Others provide similar experiences atop lower‐end hardware. To get the most benefit from your virtual platform selection, look for one that supports the technology you have already purchased but that includes the support of future needed capabilities.

Your Administrators Are Already Familiar with this Technology

The cost to educate IT staff on the use of virtualization technology can be a further expense. However, virtualization technology has been available for Microsoft servers for nearly a decade. For many, virtualization's first inroads into the IT data center actually began at the desktop level. These software applications enable the creation of virtual machines at an administrator's desktop, and are commonly used for testing and evaluating new technologies. They are also very popular with software developers in mocking up development and test environments.

As such, your systems administrators are likely already very familiar with virtualization's technologies and best practices. Although the specifics of your chosen virtual platform may require some skills training for your administrators, the overall cost to your company for moving to virtualization is likely to be much lower than with many technology insertions.

You Will Recognize Improvements to Your Business Services

Once implemented, virtualization enables levels of flexibility that were not possible using traditional physical servers alone. This flexibility comes about through the commonality of server instances, enabling a uniform server configuration across every virtual machine. The proper use of snapshots during typical administrative activities ensures that changes can be rolled back should they result in a server failure or problem. Also, the ability to create and rapidly deploy server "templates" enables your business to quickly prototype the development and deployment of new services. Each of these benefits is discussed in more detail in the following sections.

Uniform Server Configuration

When servers fail, their most impacting characteristic is often the differences in their physical composition. The installation of a patch might succeed on one server, only to crash another. One server's device configuration might work well with an application while another may experience problems. This problem is exacerbated over time as business growth and the need for additional hardware mandates new server purchases. With time passing between each purchase, the composition of earlier purchased servers is not likely to be equal to those that are purchased later on. This dissimilarity between hardware makes the job of keeping servers running more difficult, more complex, and more prone to error. With virtualization, every virtual server is functionally the same as every other, making hardware‐specific problems significantly less likely.

Configuration Rollback

Virtualization's snapshotting technologies mean that any change to a virtual server can be rolled back should that change not complete as expected. Administrators need only choose to "snapshot" the configuration of the virtual server—a typically manual step—prior to completing a change. If the change is completed successfully, the administrator can eliminate the snapshot and return the server to regular operations. If a problem occurs, "reverting to the snapshot" involves a few clicks in the server's interface. This capability prevents unexpected problems from impacting the server's operations. It further increases your servers' reliability while enabling administrators to solve problems without impacting your business.

Be Careful with Snapshots

One word of warning with snapshots: Although server snapshots are a useful tool for rolling back a configuration after a problem, their long‐term use can impact the overall performance of a virtual server. Administrators who invoke a snapshot prior to a risky configuration change or patch installation should remove the snapshot once the change is proven to be successful. Doing so ensures that the virtual server's disk processing does not incur the added overhead associated with running changes through the snapshot. This overhead grows particularly problematic when multiple, linked snapshots are created for a single server.

Rapid Service Prototyping

Many small businesses and environments shy from new IT projects due to limitations on available hardware. Most small environment budgets simply don't have the flexibility to purchase server hardware for mere service evaluation. Because of this problem, many times, new services are not properly evaluated prior to implementation. Others are not implemented at all.

Virtual machines bring flexibility to the small environment because they enable administrators to create entire mock‐up environments atop existing hardware. When virtual servers can be created through a simple copy and paste, the process to create test and evaluation environments is extremely simple. Automation components natively available within some virtualization platforms can make this process even faster through the automated personalization of OSs. By giving your administrators the ability to evaluate new software and services prior to their implementation, you gain a higher likelihood of a successful implementation down the road.

Virtualization's Spectrum of Technology, Cost, and Business Requirements

The intent of this chapter is to enable you with information about virtualization's potential benefit to the small business and small environment. These benefits start with the "hard" cost savings associated with virtualization's classic case studies: server hardware consolidation, power and cooling benefits, and software license efficiencies. However, although small businesses are likely to look first to these dollar‐for‐dollar budgetary impacts, virtualization's benefits improve operational efficiencies as well.

Some of these efficiencies can be recognized with the incorporation of virtualization's free toolsets. Others require the addition of for‐cost features. Ultimately, a spectrum exists between "no‐cost" and "for‐cost" solutions and the capabilities supported by each. That spectrum, shown in Figure 2.5, starts with basic server partitioning and ranges through the desire for centralized management and the enhancement of backups and server restores. Businesses ultimately come to the conclusion that Live Migration capabilities are necessary to ensure virtual server uptime. With Live Migration comes the extra benefits of workload load balancing and automated failover. Mating virtualization's administrative capabilities with the right monitoring and automated actions eventually gets the small business to the point where large levels of their virtual infrastructure become automated.

Figure 2.5: Virtualization's spectrum spans from no­cost to for­cost solutions and the capabilities that each provides.

The hard part is finding your business' sweet spot on that spectrum for the capabilities you need in your environment and the ones you can afford. To that end, Chapters 3 and 4 of this guide will go into further detail on the steps necessary to make the move towards virtualizing your computing infrastructure. Chapter 3 continues the conversation by asking and answering the question, "What do I need to get started with virtualization?" There, you'll learn about the technologies that virtualization relies upon, and which ones make sense for your business. Chapter 4 will continue by illuminating best practices associated with getting virtualization in the door. Its guidance will quick‐start your IT teams with the right information they need to avoid many of the common pitfalls in any virtual implementation.

What Do I Need to Get Started with Virtualization?

"All these benefits are great. But if the technology I already own doesn't support virtualization, it won't work for my business!"

Nowhere is this statement more important than with small businesses and environments. The goal of your business is to support your customers and ultimately make a profit. As such, implementing technology for technology's sake is always a losing bet, especially when your business isn't necessarily a technology company. For a technology such as virtualization to make sense for your small business or environment, it must be capable of arriving with a minimal or zero cost outlay. It must run atop your existing infrastructure, and it must provide a direct benefit to your goals of supporting your customers and making profit. If it doesn't accomplish these three things, it doesn't make sense for your business.

This chapter's goal is to provide you the technical information you need to ultimately make this decision. Whereas the first two chapters in this guide focused specifically on the cost and operational benefits associated with virtualization, this chapter will focus on a technical discussion of its hardware and software requirements. The intent here and in the next chapter is to provide a comprehensive guide to getting started. Although the content may be of a fairly high technical level, rest assured that the steps necessary to get started are actually pretty easy. Consider the information in these next chapters as your guide for ensuring that start is as successful as possible.

To begin, Figure 3.1 details what will be your grocery list of hardware and software components. These are minimally required to build a lightweight and no‐added‐cost virtualization infrastructure. You'll see in this figure that specific server components are required as well as elements at the network and storage layers. In addition to the right hardware, certain software components are required or optionally suggested. Much of the rest of this chapter will discuss each of these requirements in detail.

Your environment is likely to have most of these components already in place. Thus, repurposing them for use with your virtualization environment will be the first step in your implementation.

Figure 3.1: Your grocery list for a basic virtualization implementation with optional additional hardware and software.

Physical Servers

Obviously, to create a virtual host, you first need a physical host. Unlike many other IT services, virtualization requires large quantities of physical resources to fulfill its mission. Such is the case because a virtualization platform has the ability to scale the running of concurrent virtual machines to essentially any level. The limiting factors are the number of hosts you have as well as the resources on each of those hosts. Greater numbers of physical processors at higher speeds can support the processing needs of more virtual machines. Higher levels of onboard RAM memory mean more virtual machines can be supported by a single physical host. With this "more is greater" concept in mind, let's analyze each of the classes of server resources that you should consider.

Processors

Today's server‐class equipment typically arrives with a minimum of two processors. Many servers now include the support for four, eight, or more processors, leveraging multiple processor cores per socket. From the perspective of overall virtualization performance, the number of processor cores versus the number of sockets is irrelevant; however, the overall count of processors is important.

Licensing Processors and Cores: Although a processor versus a core may be insignificant from a raw performance perspective, be aware that virtual platform licensing may make one configuration's price different than another. For example, some virtual platform software may be priced by the number of sockets rather than the total number of processors.

A major function of the hypervisor layer is to schedule the processing of virtual machine workloads across available processors. Although a processor can process only a single instruction at a time, the rapid swapping of instructions in and out of a server's processors enables the appearance of concurrent functionality across every virtual machine. Because of this scheduling process, the more processors available for targeting by the hypervisor's scheduler means that more virtual machines can be serviced at the same time.

There is no established technical precedent associated with the number of virtual machines per onboard physical processor. Instead, effective performance monitoring is key to determining the best fit. Virtual machines with light resource requirements will use fewer processor resources than those with higher resource requirements. Understanding the anticipated resource needs of your virtual machines is important to knowing how many processors to bring to bear in a virtualization environment.

With this in mind, consider using or purchasing physical servers that have a minimum of two onboard processors for your initial implementation. Servers with four or more processors will support more virtual machines at a higher purchase cost. Going even further, servers with eight or more processors are available today for even greater expansion potential; however, these servers tend to be of much greater cost.

Memory

The second major factor in optimizing the maximum number of virtual machines per physical host relates to the amount of physical RAM memory in each server. Each running virtual machine requires the use of RAM memory that is roughly equivalent to its assigned virtual memory. Thus, if you create a virtual machine that has been assigned 2GB of virtual memory, that virtual machine when booted will consume an equal amount of physical memory.

It is for this reason that Chapter 1 discussed the fallacy of assigning too much memory to server instances. Consider the situation in which a physical server is running a very light workload, such as a file server or DNS server. In this case, if the physical server is outfitted with 4GB of memory but only uses one for its daily processing, its extra memory goes unused. Although a waste in and of itself, this situation does not create a problem for other physical servers because their memory is contained within their server chassis and not shared.

The oversubscription of memory in the virtualization context has substantially more effect. Consider a virtual host that contains 8GB of memory. If 4GB of memory are assigned to a virtual machine that only in fact needs one, the extra memory is both wasted and unavailable for use by other virtual machines on the same host. It is for this reason that virtual machine memory consumption must be carefully monitored and adjusted based on the resource needs of the virtual machine.

Physical Memory Sharing

Although this consumption of physical memory is the case with virtual machines, some virtualization platforms leverage the use of memory page table sharing. This feature allows physical memory to be shared between multiple virtual machines when the contents of each page table are equivalent. The use of memory page table sharing reduces the net effect of virtual machine memory requirements and results in an overall reduction of consumed memory when multiple virtual machines are simultaneously running.

There are, however, downsides to the use of this feature. The resource overhead associated with managing the sharing of memory page tables takes away from available resources on the host, which can result in a reduction in overall performance. Additionally, when virtual machines power on, they initially do not have the right information necessary to begin memory sharing. Thus, recently powered‐on virtual machines cannot participate. As such, even with this feature, make sure that ample physical memory is available on your virtual hosts.

It is also worth mentioning that the amount of physical memory installed to a virtual host should be maximized as much as possible. If your business can afford to augment an existing virtual host with additional memory, its addition is usually the best and least expensive change that will net the greatest benefit to the virtual environment.

Onboard Storage

Virtual hosts also require onboard disk storage for the hosting of the virtual platform itself. It is to this onboard disk storage that you will install the virtual platform's operating system (OS) and runtime files. It is also to this onboard disk storage where you may install virtual machines and their disk files as well as any supporting data such as software media.

The onboard storage requirements for most virtual platforms are relatively low in comparison with the quantity of disk storage available in today's servers. Figure 3.1 shows that a minimum of 2GB of disk storage are suggested for the virtual platform itself. This quantity is for the installation of its files and supporting software.

Due to its low cost and high levels of performance, direct‐attached storage (DAS) is where many small environments also store their virtual machine disk files. If you are repurposing existing equipment and do not have a storage‐area network (SAN) in your environment, DAS will be your only option for virtual machine storage. The correct amount of DAS required for your virtual environment will be based on a number of factors:

• Disk size for running virtual machines. You will need enough storage to support the full disk size of every concurrently‐running virtual machine. Thus, if you plan to host 10 virtual machines and each virtual machine is configured with a 40GB disk, your host will need a minimum of 400GB of DAS spread across your virtual hosts.
• Disk size for non­running virtual machines. You will find that virtual machines that are running are only one part of the total number of virtual machines in your environment. Over time, you will begin to accumulate non‐running virtual machine instances as well. These instances may be related to test and evaluation systems created for one‐time or irregular use. They may be virtual machines that are powered on only once in a while for specific uses. These virtual machines and their disks also require storage and will need to be factored into your calculations for disk storage.
• Disk size for future expansion. Because of the ease in deploying new virtual machines, many environments see a resulting explosion in virtual server instances once they have made the jump to virtualization. Your plans should include the additional disk space necessary to support your future expansion.
• Disk size for virtual machine templates. As discussed in the previous chapters, an important value‐add of virtualization is the ability to quickly create new server instances that are based on virtual machine templates. These templates are effectively virtual machines themselves that are not actively run as servers. Instead, they are used as the source for copying and pasting new server instances.
• Disk size for software media. Virtualization environments tend to make heavy use of ISO files that are created from original CD and DVD media. These files are convenient for use, as administrators do not need to locate the media and load it into the correct server's CD/DVD tray. Your additional disk space requirements for this media will depend on how much media you want to make available for use by your virtual machines.

As you can see, the disk space requirements for virtual machines can grow to become extremely large. In fact, many environments quickly find that the limitations of DAS soon become a barrier to virtual environment expansion. With the concurrent running of even 10 virtual machines requiring a half‐terabyte or more of DAS, you will quickly find that many servers are limited in the number of virtual machine disks they can host. In this case, it is likely that you will eventually decide to move to network‐based storage through an iSCSI, Fibre Channel, NAS, or NFS connection.

Clones Reduce Disk Consumption

Many virtualization platforms use a feature called virtual machine cloning to reduce the overall impact of virtual machine storage. With clones, the disk files of virtual machines are linked. Here, a source virtual machine is used as the starting point for creating additional virtual machines. Linked virtual machine disk files are much smaller in size because they contain only the differences between the source and their unique configuration.

This technology reduces the overall disk space because servers tend to be highly similar in nature. Two freshly‐built server instances can be almost completely equal in their disk configuration—with the obvious differences associated with their names and other personality elements.

Cloning technology, however, comes at a cost. The extra resources required to manage the clones and their linkages can reduce the overall performance of the virtual machine. Although clones can often be created from other clones, this multiple‐hop linking reduces performance further still. Also, although freshly‐built virtual machines are highly similar in configuration, that similarity will tend to diverge over the life of the virtual machine, reducing the disk savings efficacy of cloning technology.

Network Interface Cards

Servers that operate as virtual hosts should be outfitted with a minimum of two network interface cards (NICs) attached to your production network. These network cards are usually operated in a "teamed" configuration, with each network card providing redundancy for the other. In this configuration, should one network card fail, the other can take over and prevent a loss of service.

Although the teaming of network cards is not new technology, this network card configuration is particularly important with virtual hosts. In a physical environment, the loss of networking to a server can result in the loss of a network service. However, with virtual hosts, the loss of networking can result in the loss of numerous network services at once. Therefore, ensuring a high level of network redundancy is critical for assuring high levels of virtual machine and network service redundancy.

Using servers with two network cards is, however, only the start. More network cards are extremely useful and are often required when using advanced technologies such as iSCSI and Live Migration. It is not unheard of for virtual servers to support six network cards or more, depending on their requirements. Figure 3.2 shows an example of how a server with six network cards can be typically provisioned in a virtual environment. This server makes use of redundant iSCSI connections, redundant production network connections, and separate connections that are dedicated to Live Migration and virtual host management.

Figure 3.2: Virtual hosts often use multiple and teamed network connections for various purposes.

Additional network cards can be further used in situations in which complex networking arrangements are required. For example, a virtual host may need to support virtual machines that are in different network domains: One virtual machine may reside in your company's DMZ, while another must reside in your internal LAN.

Virtual hosts with extra onboard network cards can uniquely and inexpensively host virtual machines across trust domains through the creation of multiple virtual switches. In this situation, one virtual switch may be physically connected to your internal network while another is physically connected to your DMZ network (see Figure 3.3 for an example of this setup). The use of network VLANs makes the logical configuration of this environment inexpensive to implement and easy to manage.

Figure 3.3: Additional network cards in a server can be used to bridge network domains.

An added benefit of this configuration is that its virtual machines can all be managed from a single location, irrespective of their assigned network. By bridging network domains in this way, you can administer your DMZ servers through the same management interface that you do your internal servers. This eliminates the otherwise problematic step of physically working on servers in your DMZ or extranet because of their network limitations.

Networking

Obviously, the networking infrastructure used by your company's IT environment must be able to support the networking arrangements required by virtualization. Without getting into the specifics of networking devices and protocols, your network hardware should be able to support gigabit networking. It should additionally be able to support the teaming of network connections from a single server. This capability is available on virtually all business‐class networking equipment available today and is a requirement if you plan to team the network cards on your servers.

You may also consider creating VLANs for the purpose of segregating network traffic. One example of where this is particularly useful is in segregating iSCSI network traffic from production network traffic. iSCSI network traffic tends to be intolerant of network conditions such as latency and bandwidth contention. Because your virtual machines' hard disks are being connected to over the network, the segregation of this traffic into its own VLAN goes far in preventing transient network issues from affecting iSCSI connections.

Lastly, if you want to use Live Migration features in your virtualization infrastructure, your networking equipment must support the rapid re‐convergence of network routes after a Live Migration event occurs. This is commonly supported on most business‐class networking equipment today. When a Live Migration occurs, the physical path that clients use to connect to a virtual machine will change. When that path changes, your network and networking equipment must be able to quickly identify the change and reconfigure their internal routing tables to support the new path.

Storage

It was discussed earlier in this chapter that most environments that move to virtualization eventually find the need to segregate their storage from their servers. The physical limitations of DAS quickly become a limiting factor in the number of virtual machines that an environment can simultaneously support. Also, the sheer amount of data storage that is required for a virtualization environment often forces many organizations to move to separate storage. Although your small environment may not initially need this level of storage, you should be conscious of your storage limitations and be aware that an augmentation may be necessary down the road.

Making the move to a SAN is usually not a decision that is made lightly by any small business or environment. Although SAN costs have dropped dramatically in the past few years, any SAN purchase is likely a big decision for a small business. With this in mind, you should be aware of a few questions the answers to which you need to know should you decide to purchase SAN storage for your virtual machines:

• How much storage do you need? How much will you need? In purchasing a SAN, you must first know how much storage you plan to peel off your physical servers and re‐host on the SAN. Although most of your server instances and their OSs will likely remain on DAS, your virtual machines and other critical data will likely relocate to the SAN. In making this decision, you should also consider your future storage needs and how much extra data you believe you will need in the mediumterm future. This extra storage should relate to not only virtual machines but also templates, snapshots, and other metadata that tends to grow in size as the environment ages.
• What type of SAN will you buy? SANs these days usually come in one of two flavors: iSCSI and Fibre Channel. Although prices can be dramatically different based on any number of factors, iSCSI SANs tend to be of lower cost than those that use fibre channel. This cost difference is primarily due to iSCSI's ability to run over your existing production network. Fibre channel, however, requires its own fibre interconnects and routing/switching hardware, which adds to the overall SAN cost. Also, iSCSI SANs tend to be easier to work with, often being fully manageable by IT generalists. Fibre channel SANs can require specialized training and experience that your IT administrators may not have in‐house.
• What will you relocate to the SAN and why? It is important when making this determination to understand the total cost of SAN storage in comparison with DAS. SAN storage tends to cost far more per online gigabyte than local storage, yet it tends to be of higher reliability and better performance. Your decision about which virtual machines and other data to move to a SAN will be an important determination for that SAN's size and ultimate cost. You may find that some of your virtual machines and other data do not need the extra availability, resiliency, and features that are provided by the SAN. As such, you may split the storage of your virtual machines and other data so that only your highest‐value workloads are stored on higher‐dollar SAN storage.
• Will your SAN support multiple­host access and multipathing? Virtual environments that want to use Live Migration features for the online relocation of virtual machines must use a SAN that supports multiple and simultaneous host access. Although many virtualization platforms come equipped with their own proprietary file system or file‐locking mechanisms to ensure hosts do not overwrite each other's files, your SAN itself must support the ability for more than one machine to see a partition.
• Will your SAN support storage­level backups? Chapter 4 will talk more about the specialized backup architectures that are common to virtual environments along with their best practices. But for now, be aware that some SANs support storagelevel backups for the rapid block‐level backup of your virtual machines.

For most small businesses and environments, the decision to move from DAS to SAN‐based storage is usually aligned with a desire to increase virtual machine resiliency. This specifically relates to the ability to use Live Migration to relocate virtual machines from one host to another, a feature that requires shared storage. As your virtual environment grows, this capability will also grow in necessity. This occurs for two reasons:

• Virtual machine high availability. With the loss of any single virtual host affecting more than one virtual machine—and thus more than one network service—virtual environments eventually grow to need high‐availability features. These features not only allow an administrator to re‐host a virtual machine in preparation for a planned outage but also can automatically reboot virtual machines on alternate hosts after a host failure. Figure 1.4 in Chapter 1 shows a graphical representation of how this process works. High availability with virtual machines requires that the virtual machine disk files be stored on external SAN storage, which is why this need is usually the first step in driving a business' SAN purchase.
• Virtual machine load balancing. A secondary need for SAN storage relates to the virtual platform's ability to re‐host virtual machines when the load on one virtual host grows too great. For example, let's assume that your environment is comprised of three virtual hosts. Each virtual host contains 10 virtual machines. The processing of those 10 virtual machines is not equal at all times. Like what is shown in Figure 3.4, from time to time, one virtual machine may require greater resources to accomplish its stated mission—a mail server on a busy day or a Web server after a new product launch are two examples. In this case, you may find that the load across one of your virtual hosts is substantially greater than on the others. Your virtual platform's Live Migration feature may be able to monitor the load on each host and rearrange the hosting of virtual machines so that each host's load is balanced. This need for the optimized use of available resources is a secondary reason why many environments eventually decide to move to SAN storage for virtual machines.

Figure 3.4: Monitoring integrations in your virtual platform can watch for mismatched loads on virtual hosts and relocate virtual machines to re­balance the load.

Software

Your last category of requirements to move to virtualization will be the software that actually runs and manages that virtual environment. Numerous software vendors develop and distribute platforms with a range of features. Some vendors have greater support for enterprise customers, while others focus on small environments. Multiple software platforms from the same vendor may have different focuses as well, with some levels of software being aimed at small businesses and environments and others fulfilling the need of enterprise customers.

The goal of this guide is to provide your business with the information it needs to make an educated decision about which virtual platforms make sense. Its further goal is to assist you with understanding that some no‐cost virtual platforms are actually a good start for small businesses and environments. These no‐cost platforms provide a low‐risk starting point for businesses to make the move into virtualization with little or no initial investment.

The no‐cost platforms available today use the same fundamental technologies as found in today's enterprise products. In fact, in many cases, the no‐cost technologies—such as the hypervisor and virtual disk architectures to name a few—are actually the very same as those that are found in their more expensive brethren. You will find that the major differences between no‐cost and for‐cost solutions often relate to the level of management interaction needed by the administrator, the level of availability and resiliency features exposed in its interface, and the tools available for specialized implementations such as computer labs, user self‐service, and cloud computing needs.

This being said, implementing a no‐cost virtual platform can be only the start for your virtual software needs. You might later find the need to purchase additional software based on your needs, such as:

• Block­level backup software. Chapter 1 discussed how one benefit of virtualization is the reconfiguration of backups. These backups represent the entire virtual machine configuration in a single file. The technology used to complete this type of backup is much different than the technology used to back up systems in the traditional file‐by‐file manner. It tends to use an agentless approach, not requiring backup agents installed to each virtual machine. It is usually OS‐agnostic for the virtual machines in each virtual machine, meaning that a Linux virtual machine can be backed up using the same technology as a Windows virtual machine. In addition, it tends to be of higher performance, enabling backups to occur faster with lower levels of stress on the virtual host. Some virtual platforms include basic software for accomplishing these activities, while others do not include them at all. Upon the move to virtualization, a next step will likely be the desire to change your backup methodology to take advantage of block‐level backups for enhanced restoration capability. The software used to create and manage these block‐level backups is often an extra cost over and above that of the virtual platform.
• Disaster recovery software. Enabling cost‐effective disaster recovery is a further goal of many environments that make the move to virtualization. In effect, once virtualized and once block‐level backups are in place, the disaster recovery process involves little more than the manual or automated transfer of those block‐level backups to an alternate site. Virtual disaster recovery software also includes the necessary capabilities to bring servers back online after a disaster and to manage the later failback process once the disaster is over. Your business may later decide that disaster recovery software—and likely additional hardware—is a valuable addition to your virtual infrastructure.
• Management and monitoring software. The management tools that arrive with many virtual platforms enable basic management of your virtual servers. However, automation components are often nascent in these native tools. The same holds true for the built‐in performance‐monitoring capabilities. As your environment grows, you might find the need for additional software that can monitor your environment for known conditions and alert administrators when problems occur. Similar software can assist with automating the management of your environment, aligning your virtual environment with the other components of your IT infrastructure.
• Virtual inventory software. Some environments as they grow in size also find the widespread distribution of virtual machines to be a problem. Keeping track of virtual machines across multiple platforms, versions, and iterations can be a problematic activity, especially when license counts need to be trued‐up. Virtual inventory software can assist with these problems by identifying and reporting on the presence of virtual machines in your IT environment.

It should be obvious that these "extra" software components are likely not necessary for your initial virtualization implementation. However, these add‐on tools and many other tools like them are now available as organizations identify the need for them. Your environment will scale over time as your number of virtual machines increases. These extra tools are available for when that size grows unwieldy with native virtual platform tools alone.

So Where Do I Start?

As you can see in this chapter, there is a lot of hardware and software that needs to aggregate to make a successful virtualization implementation. However, you should also see that much of this infrastructure is likely already in your IT environment. You probably already have servers and a network. You may already have a SAN. If you've purchased servers in the last 12 to 24 months, it is likely that those servers already have the right number of processors and amount of RAM to work as virtualization hosts.

The hard part now is in repurposing that equipment to work in a virtual environment. If your business is like many small businesses, you probably don't have excess equipment available for repurposing your existing workloads. If you have 10 servers in your environment and all 10 are currently serving a stated mission for your IT environment, you may find that a new server purchase is necessary.

Your goal with this first step is to make available a single server chassis to be converted for use as a virtual host. One alternate process you can use that replaces the need for an added server purchase is to virtualize the workload of the server you want to convert to use as a virtual host. Doing so with any virtual platform's P2V tools creates a functional copy of that server as a virtual machine. Once created, you have effectively made "a backup" of that original server that can later be hosted on top of the virtual platform.

Figure 3.5: Starting on the left with low­cost add­ons and moving to the right for more expensive options, there are many ways to enhance your virtual environment.

The other question you may have after reading this chapter relates to where your money is best served for augmenting your existing hardware in preparation for your virtualization implementation. This chapter has discussed a large number of areas in which you can add dollars to gain additional performance, availability, or capacity. Figure 3.5 shows a spectrum of add‐on capabilities that you can purchase for your existing hardware to improve any of these areas. On the left of Figure 3.5 are the options with the lowest initial cost, while those on the right will be more expensive. Selecting the right expansions that align with your available funding and the features you want will be the next step in architecting your virtual infrastructure.

To assist with that architecture‐development process, Chapter 4 will continue this discussion. In Chapter 4, you'll learn more about the technical best practices that have been developed over the years. These best practices associated with management, backups, and even disaster recovery will assist you with keeping your virtual infrastructure running in good shape after you've made that initial investment.

What Are the Best Practices in Implementing Small Environment Virtualization?

In three short chapters, this guide has discussed many of the questions you and your business should be asking about virtualization. You've learned about the technologies behind virtualization, with a focus on the underpinnings that make virtualization a play for small businesses. You've also come to know the financial benefits that virtualization brings to your environment.

In the previous chapter, you got a comprehensive look at the components you'll need to get started in virtualization. Chapter 3 took a technology‐based focus on the pieces of technology you need in order to start your virtualization project. There, you learned about the types of storage available, the impact of networks and network cards, and the critical role of available memory in your physical hosts. This chapter will augment that information with the added knowledge and best practices you need to properly implement that virtual environment.

It goes without saying that any technology insertion must have a well‐defined purpose if it is to be considered successful by the business. Yet there's a problem intrinsic to many IT projects in that they're often not well‐scoped before the vendors' checks are written. In fact, Computer Associates reported in a 2007 survey (http://www.continuitycentral.com/news03155.htm) that 44% of respondents were unable to declare their server virtualization deployments a success. The primary reason was focused on the inability for respondents' businesses to quantify their project's ROI.

It is because of issues like this that this guide was developed. It was stated back in Chapter 1 that the central goal of this guide is to help you valuate the benefit virtualization provides to your small environment. That benefit is driven primarily through virtualization's low cost of entry and is augmented through its easy management.

Yet, actually seeing a benefit out of a virtualization implementation project means running that project correctly from the get go. Before you ever purchase hardware or software, or before you ever start clicking buttons in any virtual management interface, you must first identify what you want your end state to be. That process of defining the architecture ensures you don't end up with too many virtual servers attempting to use too few resources. It also ensures that you've purchased the right amount of hardware to support your virtual machines, their failover needs, and your expected level of expansion.

To Outsource or Not to Outsource

Going through the process of defining your architecture, validating any equipment you plan to purchase, and ultimately getting virtualization installed can be a big task for a small business or environment. Although actually clicking the buttons to install the software is easy, some of the surrounding tasks might require extra effort. As such, you may consider bringing in consultants or working with a Value Added Reseller (VAR) for some portion of your virtualization deployment. This can be a good thing, but it also adds expense.

Consider carefully the decision to bring in outside help. Virtualization— especially its no‐cost products—are specifically designed to be easy to deploy, even for technology generalists. Your decision on outsourcing will most likely be affected by the size and complexity of your desired environment.

Since many virtualization solutions are mature technologies, enjoying many years of successful implementations in businesses of all sizes, a set of best practices has evolved that helps ensure success. This chapter will finish the discussion by helping you understand the right way to plan and implement the rollout of your virtual environment.

The Life Cycle of a Virtualization Implementation

It can be argued that every virtualization implementation project has a life cycle just like the software itself. Irrespective of size, virtualization implementations tend to go through a series of phases. Latter phases build upon what was learned and/or implemented in the previous phase towards an expanded level of use. Figure 4.1 shows one representation of that life cycle.

Figure 4.1: Six phases that are commonly associated with a virtualization implementation.

In this image, you see a number of phases, starting at the bottom with the all‐too‐critical education process. It is upon this platform of education that the other phases lie, and from which their data and information is based. Important also in this education phase is recognition of the level of hype that exists in the virtualization ecosystem. This recognition includes an understanding of the solutions and features that are necessary for your particular needs.

The Importance of Education and Awareness

Recognizing what you need in this first phase is critically important to ensuring the success of your project. It has been discussed a number of times in this guide that technologies and features exist in today's virtualization products that are justifiably exciting. These advanced features provide the highest levels of uptime for virtual machines. They enable fantastic levels of load balancing and failover in cases of server downtime while protecting running virtual machines from planned host outages.

Yet at the same time, these added technologies might not necessarily be needed by all environments or might not be affordable by all budgets. One of the necessary activities you must undergo during this phase is in understanding your requirements as well as your budget.

You can inexpensively implement a virtualization environment today that provides basic functionality and reasonable resiliency. Such an environment can be built using existing equipment and no‐cost virtualization software, and will provide many of the financial benefits you've learned about in this guide. Once you're ready for the more high‐level benefits and features, "upgrading" to for‐cost solutions is often a simple process.

Assessing Your Environment

Once your implementation team fully understands the products and features available, the next step in the rollout is to fully understand your existing environment. In this way, the term "assessment" is multifaceted. It involves looking at your current inventory of hardware and OS installations with an eye towards which workloads will work into your planned virtual environment. Such an inventory is necessary because not all workloads work well when collocated with others atop a virtual host. As will be discussed shortly, a look at server performance is critically necessary to discover which physical servers make good virtual servers.

At a minimum, your virtualization assessment should include the following:

• An inventory of the physical servers in your environment. This inventory should include the characteristics of the physical servers being used, including installed memory, processors, and any attached peripherals. Information about networking and network domains to which servers are connected is also vitally important.
• A quantitative performance analysis of each server. This performance analysis should include performance metrics that make sense for the server in question as well as its workload. These performance metrics are possibly the most critical data you can collect, as they will document the prevailing behaviors on that server over a period of time. A listing of some sample counters as well as suggestions for how they are collected will be discussed in the following section to get you started.
• An analysis of the hardware needs to support virtualized servers. With the right level of performance information in hand, it will be possible to see what level of virtual machine collocation you can expect atop your physical hosts. In this case, and based on the performance information you have, you should be able to determine how many physical servers are required to support your virtual server needs. Although this step seems like a lot of work, it will assist with planning the hardware costs for your project.
• An analysis of failover needs. Completing the immediately previous step only gets you partway to your goal. Being successful with your virtualization implementation means also planning for failure states. For example, if you know that three virtual hosts can support ten virtual machines each, purchasing those three gives your environment the support for a total of thirty concurrent virtual machines. However, if any of those virtual hosts experiences a failure (see Figure 4.2), the failover of virtual machines will have a negative impact on the performance of your entire IT environment. This is the case because in such a failure state, a virtual host must now support more than its maximum of ten virtual machines. To prevent this, your virtualization implementation should include the added hardware capacity to support the loss of any single component.

Figure 4.2: Environments that do not properly prepare for failover can cause healthy servers to be overloaded when one server fails.

• Planning for near­term expansion. Environments that move to virtualization immediately gain the ability to rapidly spin up new servers and services when necessary. Yet this capability can be a double‐edged sword when not properly managed. Environments that don't manage the expansion of virtual machines quickly find themselves awash with far too many. Your planning should include the extra hardware and software necessary to support some measure of near‐term expansion. At the same time, you should consider planning to ensure that the expansion doesn't get out of control.
• A look at initial hosting and collocation for virtual machines. This step is particularly important for environments that elect not to implement automated failover technologies with their initial implementation. Without the ability to fail over virtual machines from one host to another with no loss of service, environments must be careful about where virtual machines are positioned. Virtual machines with high resource requirements should not be collocated with others on the same host.

Your Level of Planning Will Vary

You needn't be overwhelmed by the items in this list. The suggestions here are intended to give you a comprehensive look at all the planning that can be done for larger‐scale rollouts. If your environment takes a more measured approach, your level of pre‐deployment planning will be dramatically simpler. No matter what your size of initial deployment, however, pay careful attention to the performance measurement information in the next two sections.

Measuring Candidate Performance with Native Tools

With each of these ideas in your plan, the next step is involved with measuring the performance of those servers you may virtualize. This process is critical because there are a limited amount of resources available on any virtual host. The virtual machines running atop that host must share its available resources for their processing. As such, servers with high resource requirements often don't make good candidates for virtualization when consolidating many servers onto few is your goal.

Back in the early days of virtualization, many IT professionals took an application‐centric approach to virtualization candidacy. During those times, you would hear or read that "Exchange servers shouldn't be virtualized," or that "You should never virtualize a SQL box," or even that "Citrix and Terminal Servers don't make good candidates." However, this early focus on the applications that are installed to candidate servers was flawed. As an example, an Exchange server that serves an extremely large number of clients with massive mailbox sizes and extremely high network traffic might not be a good candidate. Yet the same server that services relatively few clients with small mailboxes and light network requirements might actually be a good fit. Thus, focusing on what is installed to your servers isn't the right approach.

In the end, that early application focus gave way to a more quantitative approach focused on actual performance measurements. Think about the servers you have in your environment today. Do you have performance counters enabled on those servers? If not, how do you know what types and level of processing they are doing during the day? Do you know whether they're particularly busy servers or relatively lightly‐used servers? Without this information, it is difficult to understand the true usage of your applications and the physical resources you've assigned to the servers that host those applications.

In the Microsoft Windows operating system (OS) the primary mechanism for identifying the level of resource use on a server is the Performance Monitor (PerfMon) tool, shown in Figure 4.3. This service measures counters across a system for metrics such as processor and memory use. It digs deep into resource usage across extremely specific counters for all kinds of system and application measurements.

Figure 4.3: PerfMon is a tool in Microsoft Windows for measuring performance across a computer.

Yet, PerfMon's comprehensive list of available counters also brings a level of confusion to the uninitiated. How do you actually use this tool—or others like it—to measure server performance? With PerfMon's hundreds or thousands of counters, which ones are important to watch?

Table 4.1 shows an example of PerfMon counters that may help get you started. The thresholds in this table are not intended to be hard‐and‐fast rules for definitively identifying candidates and non‐candidates. Instead, they are listed as example threshold values that should pique your attention towards servers that might not be the best candidates. These counters should be set up for a candidate system and run over an extended period of time—perhaps a few days or a week—to get a long‐term sense of the level of resource use for a candidate server.

Table 4.1: A table of sample counters and example thresholds.

Leveraging Easier Performance Toolsets

With all this in mind, you can see how this process of measuring candidate performance is somewhat challenging using native tools such as PerfMon. You will need to set up performance monitoring individually across multiple servers, monitor that configuration over time, and ultimately pull the results into a useable format for later reporting. You will need to know what counters to watch and what results actually have meaning for your environment. Adding to the difficulty is that the native Windows PerfMon tool is notoriously difficult to use. It has a tendency to create multiple log files with each reboot that must be later reassembled. Its reporting capabilities are ridiculously challenging to use.

Because this pre‐implementation performance assessment is so critical to virtualization success—and so natively hard to accomplish—many virtual platform vendors now provide free tools that assist. These tools (see Figure 4.4) gather information from native services such as Windows PerfMon across multiple machines at once. They provide a more streamlined approach to performance metrics gathering and reporting. More importantly, these tools tend to be preconfigured with known performance characteristics of candidate servers as well as the underlying logic that provides you with quick answers regarding which servers might work well together once virtualized. The result is that these tools provide much easier heads‐up reporting that assists you in understanding which candidate servers will and won't work well in your virtual environment.

Figure 4.4: Some virtualization platforms include software that eases the challenge of gathering quantitative performance data.

Prior to starting any virtualization implementation, it is critical to understand how potential virtual machines may work with each other. The use of these tools ensures that your completed implementation isn't resource restricted, a situation that will reduce your overall satisfaction with the result.

The Importance of Assigned Virtual RAM

Another part of your assessment process is the determination of which resources should be assigned to a server once virtualized. These resources can relate to what kinds of external drives are attached or to which networks the server should be connected.

One very important determination here is the decision about how much virtual RAM to assign to the virtual machine. Virtual environments enjoy the flexibility to assign very granular levels of RAM to virtual machines, with the added ability to adjust that assigned level on the fly. This is much different than in physical machines where adding physical RAM requires a hardware purchase and can require a complete reconfiguration of the hardware itself. Virtual environments are quite different. In a virtual environment, it is possible to very specifically assign a particular amount of RAM to a virtual machine. Changing that level at a later point is as simple as a few clicks and a virtual machine reboot.

Yet history has a role to play in this decision. Administrators have long been forced to deal with challenges in augmenting the level of RAM in a physical machine. Changing the level of RAM in a physical machine is hard. As a result, many administrators have historically overloaded their physical servers with the maximum amount of RAM, notwithstanding how much RAM that server's applications might need. As a result, many physical servers today are working with vast quantities of RAM memory that are simply not being used.

Virtual environments are much different. With many virtual machines residing atop a host, administrators can no longer afford the luxury of assigning lots of RAM to each virtual machine irrespective of its actual needs. This is the case because the level of RAM on a virtual host is a fixed resource. Assigning too much RAM to one virtual machine reduces the amount that others on the same host can use. The net result is a reduction in the total number of virtual machines that a single host can support, and an overall reduction in the value you get from your virtualization investment.

As such, a best practice is to determine and assign the lowest acceptable level of virtual RAM that a server will require in the processing of its mission. Determining this level of RAM is another activity that can be done using native performance monitoring tools such as PerfMon, or through the performance‐gathering tools provided by your virtual platform vendor. When considering the level of RAM you plan to assign to your virtual machines, look first at their resource use prior to being virtualized. Over a long‐term measurement, memory counters such as the Available MBytes counter shown in Table 4.1 will help you identify the level of RAM that is actually being consumed by the system. Once you recognize the actual amount of RAM that system requires, consider this as a starting point for its assigned virtual RAM.

Purchase & Implementation

Once you've completed the assessment of your environment, you're ready to begin looking at the virtualization solutions available on the market today. As has been discussed in earlier chapters, that analysis will look at various solutions that may or may not involve the use of no‐cost virtualization software. Most virtualization vendors today provide multiple tiers of software, with each tier providing added capabilities over those in the tier below.

Pay special attention to the information in Chapter 2 to help you identify which features you need and which you can save for later augmentation. Also, be aware of each vendor's upgrade path between tiers. Some virtual platforms can enable higher‐level tiers without requiring a wholesale replacement of the existing infrastructure. If your environment is considering a measured approach to virtualization, starting small and working your way up, a trivial upgrade path between platform tiers will make the decision to expand much easier down the road.

Converting Physical Servers to Virtual with P2V

During virtualization's early years, once the virtual platform was up and running, administrators' next step was to rebuild servers in the virtual environment. This process was challenging and involved a large amount of time, as no automated mechanism existed for converting physical servers to virtual ones. Since that time, nearly every virtualization vendor has incorporated the tools necessary to make this automated conversion possible. The process to complete this automated conversion, explained first in Chapter 1, is commonly referred to as P2V.

From a high level, the P2V process is functionally similar to the process used to image and rapidly deploy workstations. In the workstation analogy, the imaging process analyzes a source computer and creates a file in which is stored the configuration of that computer. That file is later used by the same tool to deploy the source computer's configuration to one or more other computers.

Figure 4.5: The P2V process automatically converts a physical computer to a virtual machine.

The P2V process is similar to this process in that P2V tools look at a source computer to gather its configuration (see Figure 4.5). That configuration is, however, transferred not to another physical computer. It is instead transferred into a virtual disk file that resides within your virtual environment. Where the P2V process differs from the traditional imaging process is that during the conversion, the P2V tools also change the set of drivers installed into that computer. The existing drivers that work with the physical server are replaced by new drivers that work with the virtual environment. The result when complete is that the source computer now resides also in the virtual environment and is fully ready for use once the process completes.

Although the original physical server is unchanged during the P2V process, be aware that a conversion is a one‐directional action using most toolsets. Thus, once a server has been virtualized using a P2V tool, it is a best practice to power down and decommission or repurpose the original physical server. Both copies of the server configuration should not run in your environment at the same time. As such, a good practice after P2Ving a server is to verify that the conversion completed successfully and that all the necessary data is correct on the server's virtual instance before proceeding.

Extending Backup Capabilities

Traditional server backups have always been a pain in the neck. Ensuring that each and every file and folder is correctly backed up among the tens of thousands on a server is a challenging job. Replicating that process across each of the servers in your data center virtually ensures that some are going to get missed in the process. Yet missing even a single file or folder can be a major problem if that file needs restoring. Missing that file during a server restore can fail the entire restoration process.

It is for this reason many organizations enjoy the benefits to backups that virtualization provides. As you can see in Figure 4.6, virtual machines on a virtual host have multiple ways in which they can be backed up.

Figure 4.6: Backups in a virtual environment can occur from multiple perspectives.

Depending on the virtual platform you choose as well as the capabilities of your hardware, you may elect to choose one or a combination of these mechanisms for completing your backups:

• Virtual machines can be backed up like traditional physical servers. In this configuration, virtual machines are backed up just like their physical brethren. Accomplishing this task requires the same backup client to be installed to the virtual machine as is installed to traditional physical servers. Performing backups from this perspective maintains the same backup architecture and restore capabilities as with other physical computers but gains none of the added benefits enjoyed by virtualized computers. Additionally, the processing of the backup software can consume large levels of resources on the host, reducing the performance of other virtual machines during backups.
• Virtual machines can be backed up from the perspective of the host. In this configuration, the virtual disk file for a virtual machine is backed up at once. Here, the resulting backup file is a single file that represents the entire contents of the server's hard disk. As a result, restoring that entire virtual machine's configuration requires restoring only that single file. This dramatically improves the effectiveness of backups for entire‐machine protection. Be aware, however, that this architecture may increase the effort required to complete an individual file restore, as that file will need to be extracted from the virtual disk. Using this architecture improves the performance of backups over traditional architecture because it requires no client to be installed into the virtual machine and its processing can be managed at the level of the virtual host.
• Virtual machines can be backed up from the storage perspective. Environments that leverage the use of segregated storage such as SAN and NAS enclosures add a perspective from which virtual machines can be backed up. In this configuration, the SAN or NAS enclosure itself can be configured to back up the virtual machine disk files on behalf of the virtual host. Offloading the processing of backups to the storage eliminates its performance impact on the virtual host itself.
• The virtual host configuration itself can be backed up. In addition to backing up the virtual machines on a host, that host's configuration can and should be backed up as well. Doing so ensures that individual files can be restored in the case of a loss, and provides a way to restore the virtual host in the case of a loss.

The Problem with Transactional Databases

Getting good backups of your servers' file systems is one thing. Capturing a successful backup of a running application is quite another. There is a known issue with some virtual backup solutions that back up virtual machines from the perspective of the host. These backup solutions do not have a mechanism for instructing transactional databases—such as SQL, Exchange, or Active Directory (AD) databases, for example—to correctly pause themselves for the purpose of the backup. Without the right pausing of databases during the backup, it is possible that the restore of a virtual disk may return the database in an inconsistent state.

The technical term for this pausing is called "quiescence" and is a necessary step for databases like the ones discussed earlier to be immediately available upon a virtual disk restore. For the Microsoft Windows OS, the most commonly used mechanism today for ensuring quiescence is the use of the Volume Shadow Copies (VSS) service in the virtual machine's OS. If you plan to virtualize workloads that make use of transactional databases and plan to use backups from the host's perspective, make sure that your backup solution supports the integration with the VSS service in any Windows‐based virtual machines.

Adding Affordable Disaster Recovery

The final phase in this chapter's representation of the virtualization implementation life cycle is one that many businesses realize once they've made the move to virtualization. Specifically, smart organizations quickly realize that virtualization's augmentation to the architecture of backups readily enables new disaster recovery options.

To best explain how these disaster recovery options are made available through virtualization, consider first how disaster recovery and planning is done in physical environments. In these environments, the first step in creating a secondary site is to bring that site online. Bringing that site online requires high‐speed network connectivity between primary and secondary sites. It also requires the purchase of hardware that is exactly the same between the primary and secondary site. On that hardware is needed a configuration that is exactly the same as well between the primary and backup sites. This precise level of similarity is necessary so that all the functionality and data from the primary site can still be used after the migration to post‐disaster operations.

Yet, this requirement in an all‐physical environment is operationally challenging. Creating two servers that are functionally equivalent requires double the hardware and the effort. Maintaining that exact similarity over time is an operational headache as well, with every configuration change needing replication to the alternate site. Software packages are available that assist in automatically replicating the configuration changes, but such a site still requires an effective doubling of hardware, software, and other infrastructure elements.

Virtualization changes the game significantly in part due to the way it handles backups of virtual machines. One of the options for backups mentioned in the previous section was for virtual disk files to be backed up from the perspective of the host. This single‐file backup of an entire virtual machine quickly and easily captures the exact state of that virtual machine at the time of its backup. Also in that section it was stated that restoring such a virtual machine required little more than restoring its single file to a virtual host.

Now, frame these same capabilities around the restoration of that virtual machine instead at a secondary site. Once a business has their backup solution in place and virtual disk files are being backed up in easy‐to‐restore formats, the only remaining action left to enable disaster recovery is the replication of those disk files to an alternate location. Figure 4.7 shows a graphical representation of how this might work.

Figure 4.7: Replicating virtual machine disk files to an alternate location provides a cost­effective disaster recovery solution.

The process to replicate these backups from a primary to a disaster recovery site can occur through an automated mechanism—either as a component of the backup or through a dedicated replication solution—or can be manually transferred as necessary. Your level of automation required in the replication is directly related to your requirements for returning to full operations after a disaster event. Also a factor in this architecture is the level of granularity you require for your backed up data. Businesses with little tolerance for lost data will want solutions that back up virtual machines more‐or‐less continuously. Other businesses with greater levels of tolerance can leverage solutions that transfer backups on a scheduled or irregular basis.

Implementing Virtualization Involves Technology and a Plan

Again, all the technical information in this and the previous chapter are written to give you a holistic view of the options available in making the jump to virtualization. Your individual needs may require only a single server and a few virtual machines, a situation that reduces your level of required planning to begin an implementation. Projects with larger scopes and more complex needs will want to include each of the planning steps and best practices outlined in this chapter.

No matter your needs, this guide has attempted to show you how the jump to a virtualized infrastructure is a good thing for small businesses and environments. It increases your level of IT agility while at the same time reducing your overall operating costs. It provides levels of hard benefit to your business not seen in most IT projects. Above all, virtualization enables dramatically greater levels of flexibility for the processing needs of your business. With the right information in hand, your job now is to determine whether and where it fits in your overall business plans.

---