Chris McCain - Mastering VMware® Infrastructure3

Now let's consider the path to virtualization. Let's look at several options L2V might have if they move in the direction of server consolidation using the VI3 platform. Since L2V already owns a storage device, we'll refrain from including that as part of the return on investment (ROI) calculation for their virtual infrastructure. L2V is interested in the enterprise features of VMotion, DRS, and HA, and therefore they are included in each of the ROI calculations.

The prices provided in the ROI calculations were abstracted from the small and medium business section of Dell's website, at http://www.dell.com. The prices should be used only as a sample for showing how to determine the ROI. It is expected that you will work with your preferred hardware vendor on server make, model, and pricing while using the information given here as a guide for establishing the right hardware for your environment and budget.

Each of the following three ROI calculations identifies various levels of availability, including single server failure, two-server failure, or no consideration for failover. All of the required software licenses have been included as part of the calculation; however, annual licensing fees have not been included since there are several options and they are recurring annual charges.

Scenario 1: Quad Core 3 Server Cluster

Scenario 2: Quad Core Four Server Cluster

Although both scenarios present a different deployment, the consistent theme is that using VI3 reduces the cost per server by introducing them as virtual machines. At the lowest cost, virtual machines would each cost $898, and even at the highest cost, they would run $2,394 per machine. These cost savings do not include the intrinsic savings on power consumption, space requirements, and additional employees required to manage the infrastructure.

Though your environment may certainly differ from the L2V Inc. example, the concepts and processes of identifying the ROI will be similar. Use these examples to identify the sweet spot for your company based on your existing and future goals.

With several vendors and even more models to choose from, it is not difficult to choose the right server for a VI3 deployment. However, choosing the best server for the job means understanding the scalability and fiscal implications while meeting current and future needs. The samples provided are simply guidelines that can be used. They do not take into consideration virtual machines with high CPU utilization. The assumption in the previous examples is that memory will be the resource with greater contention. You may adjust the values as needed to determine what the ROI would be for your individualized virtual infrastructure.

No matter the vendor or model selected, ESX Server 3.5 has a set of CPU and memory maximums, as shown in Table 2.1.

Where appropriate, each chapter will include additional values for ESX Server 3.5 maximums for NICS, storage configuration, virtual machines, and so forth.

Table 2.1: ESX Server 3.5 Maximums

In addition to the choice of server vendor, model, and hardware specification, the planning process involves a decision between using ESX Server 3.5 versus ESXi 3.5. This chapter will cover the installation of ESX Server 3.5, while Chapter 13 will examine the specifics of ESXi 3.5.

Installing ESX Server 3.5 can be done in a graphical mode or a text-based installation, which limits the intricacy of the screen configuration during the installation. The graphical mode is the more common of the two installation modes. The text mode is reserved for remote installation scenarios where the wide area network is not strong enough to support the graphical nature of the graphical installation mode.

Before we offer step-by-step instructions for installing ESX Server, it is important to review some of the functional components of the disk architecture upon which ESX Server will be installed. Because of its roots in Red Hat Linux, ESX Server does not use drive letters to represent the partitioning of the physical disks. Instead, like Linux, ESX Server uses mount points to represent the various partitions. Mount points involve the association of a directory with a partition on the physical disk. Using mount points for various directories under the root file system protects the root file system by not allowing a directory to consume so much space that the root becomes full. Since most folks are familiar with the Microsoft Windows operating system, think of the following example. Suppose you have a server that runs Windows using a standard C: system volume label. What happens when the C drive runs out of space? Without going into detail let's just leave the answer as a simple one: bad things. Yes, bad things happen when the C drive of a Windows computer runs out of space. In ESX Server, as noted, there is no C drive. The root of the operating system file structure is called exactly that: the root. The root is noted with the / character. Like Windows, if the / (root) runs out of space, bad things happen. Figure 2.2 compares Windows disk partitioning and notation against the Linux disk partitioning and notation methods.