VMware vSphere Resource Management Essentials

By Jonathan Frappier
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

vSphere is the flagship suit of Server virtualization, cloud deployment, and management. VMware vSphere comes with features that help you prepare a robust foundation to build virtual environments. You might have an already-built vSphere deployment, but managing the resources of your vSphere environment is crucial in order to save time and improve productivity.

This practical guide provides readers with a high-level understanding of the various components, methodologies and general best practices for maintaining and managing resources in a virtual environment.

Readers will begin the book with an explanation of the requirements for ESXi, the groundwork for VMware vSphere, and move through a comprehensive study of how resources are supplied. We’ll then progress with showing you the characteristics that enable resource and virtual machine availability.

With a solid understanding of the requirements to build and run your environment, you then move on to understanding how ESXi manages resources such as CPU, memory, disk, and networks for multiple virtual machines and how it ensures resource availability. Finally, you will be made aware of the options available with Vmware vSphere to automate and monitor your environment.

Readers will go through a learning curve of understanding the components, identifying the course of action, and putting it to practice.

Publication date:
February 2014
Publisher
Packt
Pages
112
ISBN
9781782170464

 

Chapter 1. Understanding vSphere System Requirements

VMware vSphere allows organizations to achieve extremely high levels of resource utilization for both new and existing physical servers by allowing administrators to easily virtualize and consolidate existing servers. By consolidating multiple servers and applications onto a single physical server, organizations can maximize their Total Cost of Ownership (TCO) by using more of the resources provided by the physical server. However, like any other system, there are certain requirements vSphere needs to fulfill in order to function properly. In addition to the system requirements for various vSphere components that make up a working environment, it also brings back the lost art of true infrastructure design. This ensures that you understand the requirements of the systems and applications you will be virtualizing so that they can operate according to your organization's Service Level Agreements (SLA).

In this chapter, we will review the requirements for installing various components of vSphere, including ESXi and vCenter. Also, we'll learn about the tools available to validate your hardware and look at the basics of determining resource utilization for your existing servers and applications.

The topics we'll cover in this chapter are as follows:

  • Understanding ESXi system requirements and general best practices

  • Understanding vCenter system requirements and options

  • Understanding the features of vSphere

  • Reviewing the basic components of a vSphere environment

  • Understanding configuration maximums

  • Determining resource utilization requirements

 

ESXi system requirements


VMware vSphere Hypervisor, also known as ESXi, is the foundation on which you will build your vSphere environment. A hypervisor is simply software that manages and assigns physical resources to virtual systems. Hypervisors are classified into two types: type 1 and type 2. Type 1 hypervisors are installed onto bare metal hardware such as ESXi. Type 2 hypervisors are installed on top of an existing operating system, for example, a VMware Workstation, which is installed on Windows or Linux, or VMware Fusion, installed on OSX.

ESXi is installed on your physical server to a hard drive, USB flash drive, or a built-in chip directly from manufactures such as Hewlett Packard. Alternatively, it can be directly installed into the memory using an advanced feature called auto deploy. By using vSphere, applications that may have otherwise not utilized all of the resources in a physical server will now be shared among multiple Virtual Servers (VMs) and the applications running on them. VMware previously released other hypervisors, for example, VMware server that was installed on top of Windows systems that allowed you to create virtual servers. At the time of writing this, VMware is committed to using ESXi as its type 1 hypervisor.

As you have most likely become accustomed to other operating systems and applications, there are specific system requirements based on the version of ESXi that you are installing. The VMware Knowledge Base maintains up-to-date information not only about the system requirements for the version of ESXi that you are running, but also about known problems and steps for troubleshooting error messages you may encounter.

VMware KB 2052329 provides a list of the minimum requirements for installing ESXi 5.5 available at http://kb.vmware.com/kb/2052329.

If you have an older version of ESXi that you need to continue to support, you can find the requirements in VMware KB 1003661 available at http://kb.vmware.com/kb/1003661.

Let's review some of the resource requirements for ESXi 5.5 as follows:

  • A 64-bit x86 processor with at least two cores, such as an Intel Xeon E5-2640 or AMD Opteron 6320, which supports hardware virtualization (Intel VT-x or AMD RVI).

  • A minimum of 4 GB RAM to install ESXi is required. However, this is truly a minimum requirement as the consolidation ratios and application requirements you are targeting will ultimately drive the amount of RAM in your servers. We will discuss consolidation ratios later in this chapter.

  • At least one gigabit network adapter.

  • A supported storage controller and a device with minimum of 1 GB of space to install ESXi and 5.2 GB to create the scratch partition.

Additionally, you will want to confirm that all of your hardware is supported by visiting the VMware Compatibility Guide available at http://vmware.com/go/hcl.

Now, if you are thinking, "Oh great, I need to go through all the hardware in my server to make sure it works!", be rest assured that VMware has a vast partner network. Therefore, validating servers from vendors such as HP, Dell, and Cisco can be done with just a few clicks, as seen in the following screenshot:

In the preceding screenshot, we searched for Rackmount servers that are compatible with ESXi 5.5 from HP. Selecting these three options and clicking on the Update and View Results button give us a list of servers that match our search, as shown in the following screenshot:

Of course, if you build your own servers, this process may be a little more manual since you will have to verify each component.

One last site you should bookmark and get in the habit of visiting is the VMware Community site. The Community site is filled with people passionate about virtualization, supporting and giving back to others in the virtualization community. It's a great place to ask questions and see what others have been experiencing. For example, maybe you are trying to decide between two quad-port NICs for your server, which are both in the compatibility guide, but the chipset on one is more prone to errors than the other. If that were the case, I bet there would be a discussion on this! You can find the VMware Community site at https://communities.vmware.com/welcome.

Now that we know the requirements and how to find the requirements for your specific environment, installing ESXi on a server, starting to build virtual machines, or even converting current physical machines to virtual machines is within your reach. If you think consolidating multiple physical servers onto a single ESXi host is amazing, wait until you see what managing ESXi hosts with vCenter can do.

 

vCenter components


While ESXi is the foundation on which we build our virtual environment, the amazing features that allow greater resource utilization of our physical servers comes from joining multiple ESXi hosts together and managing them with VMware vCenter. vCenter itself comes in two different versions, standard and foundation. The foundation edition is designed for small deployments, supporting only three hosts, and is generally packaged into essentials kits. The standard edition is required for anything beyond three managed hosts.

This probably won't be the last time I say this, but just as any other application, you need to plan your vCenter deployment properly to ensure it can support your environment. VMware provides two basic options for deploying vCenter: either installed as an application on top of Microsoft Windows or as a prepackaged Linux virtual appliance. The virtual appliance is not new to vSphere 5.5, but VMware has expanded capabilities of the appliance in vSphere 5.5 to support up to 100 ESXi hosts or 3,000 virtual machines using the built-in PostgreSQL database or up to 1000 hosts or 10,000 virtual machines with an external Oracle database. You can find more information in the vSphere Configuration Maximums guide, which we will review shortly. It is available at http://kb.vmware.com/kb/2052334.

As of vSphere 5.1, VMware separated many functions that were once bundled together into separate services, allowing you for having greater control (and greater complexity) of your vCenter deployment. The main components you need to be aware of are as follows:

  • vCenter

  • vCenter Single Sign-On

  • vCenter Inventory Service

  • vSphere Web Client

Covering each of these components is beyond the scope of this book. For a more in-depth look at each component, check out Implementing VMware vCenter Server, Konstantin Kuminsky from Packt Publishing or Mastering VMware vSphere 5.5 from Sybex, Nick Marshall and Scott Lowe and several other authors who are prominent members of the VMware community.

vCenter also requires a database server to store configuration information, collect statistics about the environment, and perform various tasks to maintain a healthy database. The database platform you require (yes, I'm going to say it again) needs to be planned properly in order to support your requirements. vCenter can be installed on the same server as your database, but I would treat defining system requirements as if they were going to be on separate servers.

VMware considers a small deployment for vCenter up to 100 hosts or 1000 VMs; for many organizations, this is probably adequate but can support much more. The resources required for vCenter to run efficiently are based on your host or VM inventory.

A Simple Install, which is a streamlined installation of vCenter, vCenter SSO, vCenter Inventory Service, and the web client, has the following requirements:

  • 2x 64-bit processor cores (such as ESXi; these can be either Intel or AMD) with a speed of 2 GHz

  • 12 GB of memory

  • 40 to 60 GB of disk space

  • 64-bit database server

Again, it's important to emphasize that this is in addition to your database server requirements. While the database server requirements, installation, and configuration are beyond the scope of this book, let's take a quick look at the system requirements for a database server.

Microsoft recommends a 2 GHz or a faster processor of 4 GB of RAM along with 3.6 GB of free disk space for various SQL Server components. When added to the vCenter server requirements, you have what may be one of the larger servers in your environment. You should consult your DBA team, or if it is a one-man show, refer to Google and the SQL documentation online at http://technet.microsoft.com/en-us/library/ms143506(v=sql.105).aspx.

 

Understanding vSphere features


So we know that vCenter is available in two different versions, but what is really important is the features that vCenter unlocks. VMware is constantly innovating and adding new features, so it's best to visit the VMware website for the latest version and features available.

There are currently three editions of vSphere: Standard, Enterprise, and Enterprise Plus. Understanding what features are available in each edition is the most important step in building your virtualization plans so that you can purchase the edition that meets your requirement. Let's look at the three versions and what is available in each one of them. When you get to in Chapter 3, Advanced Resource Management Features, you'll notice that these line up pretty closely, so if you are unfamiliar with a feature mentioned in the following table, we will cover it shortly.

Feature

Standard

Enterprise

Enterprise Plus

vMotion

Yes

Yes

Yes

Storage vMotion

Yes

Yes

Yes

High Availability (HA)

Yes

Yes

Yes

Fault Tolerance (FT)

Yes

Yes

Yes

Hot Add

Yes

Yes

Yes

App HA

 

Yes

Yes

Distributed Resource Scheduler (DRS)

 

Yes

Yes

Storage DRS

  

Yes

Flash Read Cache

  

Yes

Virtual Distributed Switch (vDS)

  

Yes

Network I/O control

  

Yes

Storage I/O control

  

Yes

Host Profiles and auto deploy

  

Yes

VSAN

Licensed separately

I added VSAN to this list and the book even though it is scheduled to be a separate product (VSAN is currently still in beta at the time of writing this); it is one of the most exciting pieces of technologies since virtualization.

As a VMware administrator, many of us would select Enterprise Plus for our licenses, but as always, cost is going to be a factor. As we review each of the features and their ability to help manage resources, you will be able to make a more informed decision on which version is right for your organization.

 

Topology basics


Now that you are familiar with the system requirements to get ESXi and vCenter installed, and have a list of the features available in different versions, it's time to look at how a typical vSphere deployment is organized. Different features of vSphere are configured and made available at various levels, so understanding each feature is critical. A basic vCenter environment will contain a data center, and within the data center, you create clusters. Hosts are placed into a cluster and then VMs are created on a host.

Understanding vSphere data center

The topology of a vSphere environment is very similar to what you might see from a physical perspective. After installing ESXi and vCenter, one of the first items you will be asked to create is a data center. A data center is, in its simplest form, the container (or a storage area if we are relating it to a physical environment) where your resources are stored. Since we live in a virtual world, your vCenter data center is not tied to one physical location. In fact, if you really wanted, you could create several vCenter data centers even if all the servers were in the same physical location, but there is not much need for that. It's common to mirror your vCenter data centers to physical locations of your ESXi hosts. For example, if you have a physical data center in Boston and Atlanta, you might create two data center objects in vCenter, one for Boston and one for Atlanta, which contain the physical resources located at each data center. Once your data center is created, you could move on to add hosts and leveraging features such as vMotion; however, you would be missing out on one of the critical areas as it relates to managing resources—vCenter clusters.

Familiarizing yourself with a vSphere cluster

Clusters are created within data centers and again, because this is all virtual, you could create as many clusters as you like. Clusters are a collection of ESXi hosts that can share resources amongst each other. In fact, two of the most important resource and availability features vSphere offers are enabled at the cluster level: High Availability (HA) and Distributed Resource Scheduler (DRS). There are several other settings configured at the cluster level that we will cover in Chapter 3, Advanced Resource Management Features.

What is a vSphere host?

As mentioned in the previous section, within a cluster, we add ESXi hosts. There is quite a bit of configuration done at a host level, but without a host, we cannot virtualize any servers or desktops. As a quick aside, much of what we talk about in this book relates to server virtualization, but both ESXi and vCenter also provide the necessary infrastructure for virtual desktops. Yes, you can virtualize your desktops as well! If you are interested in learning more about Virtual Desktop Infrastructure (VDI), check out Implementing VMware Horizon View 5.2, Jason Ventresco, Packt Publishing.

Now that we have our hosts in a cluster and our cluster in a data center, we can start creating VMs or even use a tool such as VMware Converter to take an existing physical server and convert it into a virtual server. Here is what a basic vSphere environment might look like:

Using the preceding screenshot as a reference, we have a vCenter Server called vc-l-01a and a data center called Datacenter Site A. Within this data center, we have a cluster called Cluster Site A, and within the cluster, we have three ESXi hosts; on the hosts, there are five VMs.

 

Remembering configuration maximums


Up until now, we have focused on the minimum requirements to run ESXi and vCenter; however, it is important to remember that there are actually maximum supported configuration settings as well. For example, while we have seen that vCenter, with an appropriate amount of resources, can manage up to 400 hosts or 4,000 VMs, a cluster can only contain 32 ESXi hosts. In this scenario, if you had 400 hosts, you would have to create 13 clusters within your data center (or data centers) to support all of those hosts. Depending on your organization, you may also have deployed multiple vCenter servers to manage all of those hosts.

All of the various components that make up a vSphere environment have various configuration maximum settings. Depending on your physical to virtual consolidation ratio, you could find yourself in a scenario where you were within the limits of one configuration maximum setting but are constrained by another. For example, you can configure up to 10 virtual NICs per virtual machine but can only have 1016 active ports per host. If you were able to run 102 VMs on a single physical host and each VM had 10 active virtual NICs, then you would need 1020 active ports, which is above the configuration maximum of 1016 per host. This scenario might be a bit extreme, but it's used to point out that just because you comply with the maximum configuration settings for one resource, it does not mean it would work with another.

Let's take a look at some of the more common configuration maximum settings.

Virtual machine maximums (per VM)

Every component within the hierarchy of a vSphere environment has certain maximum settings. Here are some common VM configuration maximums:

  • 64 virtual CPUs

  • 1 TB of RAM

  • 62 TB of virtual disk size

  • 10 virtual NICs

  • 20 USB devices

ESXi host maximums (per host)

Like the VM configuration maximum settings mentioned in the previous section, ESXi hosts also have several maximum settings you need to be aware of when you need to design and configure your host, mentioned as follows:

  • 320 logical CPUs

  • 512 VMs

  • 4096 virtual CPUs (total number of assigned virtual CPUs across all VMs)

  • 32 virtual CPUs per physical core

  • 4 TB of RAM

  • 1 VSWP swap file per virtual machine

  • 256 iSCSI, FC LUNs, or NFS mounts

  • 64 TB of datastore volume size

  • 256 volumes per host

  • 24 e1000e 1 GB ethernet ports (Intel PCI-e)

  • 8 bnx2x 10 GB ethernet ports (Broadcom)

  • Eight 10 GB and four 1 GB ports (combined)

Cluster maximums

Cluster maximums are one of the more likely areas you will reach when you use configuration maximum settings during your design and implementation. Some of them are mentioned as follows:

  • 32 hosts

  • 4000 virtual machines

  • 512 virtual machines per host

  • 1600 resource pools per host

Like anything else, configuration maximums tend to change from version to version, so make sure you check what the configuration maximums are for your version of vSphere. Configuration maximums for vSphere 5.5 can be found at http://www.vmware.com/pdf/vsphere5/r55/vsphere-55-configuration-maximums.pdf.

 

Determining resource utilization requirements


Until now, we have focused on the minimum resource requirements to run ESXi and vCenter, but how do you determine the needs specific to your environment? Before virtualization, in many cases, the physical servers you were buying were so much more powerful than what many needed. This is why sizing became somewhat of a lost art.

For those hoping to find a magical catch-all formula that will work in every scenario, you'll have to keep looking. Remember every environment is unique, and even where similarities may arise, the use case your organization has, will most likely be different from another organization. Beyond your specific VM resource requirements, the hosts you are installing ESXi on will also vary; the hardware available to you will affect your consolidation ratio (the number of virtual machines you can fit on a single host). For example, if you have 10 servers that you want to virtualize, and you have determined each requires 4 GB of RAM, you might easily virtualize those 10 servers on a host with 48 GB of memory. However, if your host only has 16 GB of memory, you may need two or three hosts in order to achieve the required performance.

Another important aspect to consider is when to collect resource utilization statistics about your servers. Think about the requirements you have for a specific server; let's use your finance department as an example. You can certainly collect resource statistics over a period of time in the middle of the month, and that might work just fine; however, the people in your finance department are more likely to utilize the system heavily during the first few days of the month as they are working on their month end processes. If you collect resource statistics on the 15th, you might miss a huge increase in resource utilization requirements, which could lead to the system not working as expected, making unhappy users.

One last thing before we jump into some example statistics; you should consider collecting these statistics over at least two periods for each server:

  • First, during the normal business hours of your organization or the specific department, during a time when systems are likely to be heavily utilized

  • The second round should include an entire day or week so you are aware of the impact of after hours tasks such as backups and anti-virus scans on your environment

It's important to have a strong understanding of the use cases for all the systems you will be virtualizing. If you are running your test during the middle of the month, you might miss the increase of traffic for systems utilized heavily only at the end of the month, for example, accounting systems. The more information you collect, the better prepared you will be to determine your resource utilization requirements.

There are quite a few commercial tools available to help determine the specific resource requirements for your environment. In fact, if you have an active project and/or budget, check with your server and storage vendor as they can most likely provide tools to assess your environment over a period of time to help you collect this information. If you work with a VMware Partner or the VMware Professional Services Organization (PSO), you could also work with them to run a tool called VMware Capacity Planner. This tool is only available to partners who have passed the corresponding partner exams.

For purposes of this section, however, we will look at the statistics we can capture natively within an operating system, for example, using Performance Monitor on Windows and the sar command in Linux.

If you are an OS X user, you might be wondering why we are not touching OS X. This is because while Apple allows virtualizing OS X 10.5 and later, it is only supported on the Apple hardware and is not likely an everyday use case. If your organization requires virtualizing OSX, ESXi 5.1 is supported on specific Mac Pro desktops with Intel Xeon 5600 series processors and 5.0 is supported on Xserve using Xeon 5500 series processors. The current Apple license agreement allows virtualizing OSX 10.5 and up; of course, you should check for the latest agreement to ensure you are adhering to the license agreement.

Monitoring common resource statistics

From a statistics perspective, there are four main types of resources you generally monitor: CPU, memory, disk, and network. Unless you have a very chatty application, network utilization is generally very low, but this doesn't mean we won't check on it; however, we probably won't dedicate as much time to it as we do for CPU, memory, and disk.

As we think about the CPU and memory, we generally look at utilization in terms of percentages. When we look at example servers, you will see that having an accurate inventory of the physical server is important so we can properly gauge the virtual CPU and memory requirements when we virtualize. If a physical server has dual quad core CPUs and 16 GB of memory, it does not necessarily mean we want to provide the same amount of virtual resources (you will learn why in the next chapter).

Disk performance is where many people spend the least amount of time, and those people generally have the most headaches after they have virtualized. Disk performance is probably the most critical aspect to think about when you are planning your virtualization project. Most people only think of storage in terms of storage capacity, generally gigabytes (GB) or terabytes (TB). However, from a server perspective, we are mostly concerned with the amount of input and output per second, otherwise known as IOPS and throughput. We break down IOPS in into reads and writes per second and then their ratio by comparing one with the other. Understanding your I/O patterns will help you design your storage architecture to properly support all your applications. Storage design and understanding is an art and science by itself.

The vSphere High Performance Cookbook, Prasenjit Sarkar, Packt Publishing has an entire chapter dedicated to storage; Troubleshooting vSphere Storage, Mike Preston, Packt Publishing provides you with the key steps to help spot problems with storage from a vSphere perspective. Finally, one of the most in-depth books on storage is Storage Implementation in vSphere 5.0 from VMware Press, Mostafa Khalil (one of the original VMware Certified Design Experts in VCDX).

Sample workload

Let's break this down into a practical example so we can see how we are applying these concepts. In this example, we will look at two different types of servers that are likely to have various resource requirements: Windows Active Directory Domain Controller and a CentOS Apache web server. In this scenario, let's assume that each of these server operating systems and applications are running on dedicated hardware, that is, they are not yet virtual machines.

The first step you should take, if you do not have this already, is to document the physical systems, their components, and other relevant information such as computer or DNS name, IP address (es), location, and so on. For larger environments, you may also want to document installed software, user groups or departments, and so on.

Collecting statistics on Windows

On Windows servers, your first step would be to start performance monitoring. Perform the following steps to do so:

  1. Navigate to Start | Run and enter perfmon.

  2. Once the Performance Monitor window opens, expand Monitoring Tools and click on Performance Monitor. Here, you could start adding various counters; however, as of Windows 2008/Windows 7, Performance Monitor includes Data Collector Sets.

  3. Expand the Data Collector Sets folder and then the System folder; right-click on System Performance and select Start. Performance Monitor will start to collect key statistics about your system and its resource utilization.

  4. When you are satisfied that you have collected an appropriate amount of data, click on System Performance and select Stop. Your reports will be saved into the Reports folder; navigate to Reports | System, click on the System Performance folder, and finally double-click on the report to see the report.

In the following screenshot for our domain controller, you can see we were using 10 percent of the total CPU resources available, 54 percent of the memory, a low 18 IOPS, and 0 percent of the available network resources (this is not really uncommon; I have had busy application servers that barely break 2 percent).

Now let's compare what we are utilizing with the actual physical resources available to the server. This server has two dual core processors (four total cores) running at 2 GHz per core (8 GHz total available), 4 GB of memory, two 200 GB SAS drives configured in a RAID1, and a 1 Gbps network card.

Here, performance monitor shows averages, but you should also investigate peak usage. If you scroll down in the report, you will find a menu labeled CPU. Navigate to CPU | Process. Here you will see quite a bit of data, more than the space we have to review in this book; however, if you scroll down, you will see a section called Processor User Time by CPU. Here, your mean (that is, average) column should match fairly closely to the report overview provided for the total, but we also want to look at any spikes we may have encountered. As you can see, this CPU had one core that received a maximum of 35 percent utilization, slightly more than the average suggested.

If we take the average CPU utilization at 10 percent of the total CPU, it means we will theoretically require only 800 MHz of CPU power, something a single physical core could easily support. The, memory is also using only half of what is available, so we can most likely reduce the amount of memory to 3 GB and still have room for various changes in operating conditions we might have not encountered during our collection window. Finally, having only 18 IOPS used means that we have plenty of performance left in the drives; even a SATA 7200 RPM drive can provide around 80 IOPS.

Collecting statistics on Linux

Now let's look at the Linux web server to see how we can collect this same set of information using sar in an additional package with sysstat that can monitor resource utilization over time. This is similar to what you might get from top or iotop. The sysstat package can easily be added to your system by running yum install sysstat, as it is a part of the base repository (yum install sysstat is command format).

Once the sysstat package is installed, it will start collecting information about resource utilization every 10 minutes and keep this information for a period of seven days. To see the information, you just need to run the sar command; there are different options to display different sets of information, which we will look at next.

Here, we can see that our system is idle right now by viewing the %idle column.

A simple way to generate some load on your system is to run dd if=/dev/zero of=/dev/null, which will spike your CPU load to 100 percent, so, don't do this on production systems! Let's look at the output with some CPU load. In this example, you can see that the CPU was under load for about half of the 10-minute collection window.

One problem here is that unless the CPU spike, in this case to 100 percent, was not consistent for at least 10 minutes, we would potentially miss these spikes using sar with a 10-minute window. This is easily changed by editing /etc/cron.d/sysstat, which tells the system to run this every 10 minutes. During a collection window, one or two minutes may provide more valuable detail. In this example, you can see I am now logging at a five-minute interval instead of 10, so I will have a better chance to find maximum CPU usage during my monitoring period.

Now, we are not only concerned with the CPU, but we also want to see memory and disk utilization. To access those statistics, run sar with the following options:

  • The sar –r command will show RAM (memory) statistics. At a basic level, the items we are concerned with here would be the percentage of memory used, which we could use to determine how much memory is actually being utilized.

  • The sar –b command will show disk I/O. From a disk perspective, sar –b will tell us the total number of transactions per second (tps), read transactions per second (rtps), and write transactions per second (wtps).

As you can see, you are able to natively collect quite a bit of relevant data about resource utilization on our systems. However, without the help of a vendor or VMware PSO who has access to VMware Capacity Planner, another commercial tool, or a good automation system, this can become difficult to do on a large scale (hundreds or thousands of servers), but certainly not impossible.

 

Summary


In this chapter, we looked at the various resource requirements to build a working vSphere environment, including the resource requirements for both ESXi and vCenter. We also reviewed the VMware Compatibility Guide to validate the hardware where installing ESXi would be supported.

We then wrapped up by looking at the various resources we want to support when we create virtual machines to ensure the performance is acceptable and within your organization's SLAs. What we saw in the two examples is not different from what many organizations face; they have invested in resources by purchasing these servers. However, it will not receive the full Return on Investment (ROI) because the systems are not being more heavily leveraged.

In the next chapter, we will see how VMware vSphere can utilize server resources to provide your organization with a great ROI efficiently while most likely decreasing its TCO because of its ability to consolidate several physical machines onto a single host. This provides greater availability that you could achieve without the use of VMware vSphere.

About the Author

  • Jonathan Frappier

    Jonathan Frappier is a hands-on technology professional with over 15 years of experience in VMware-virtualized environments, focusing on system interoperability. He has specialization at the intersection of system administration, virtualization, security, cloud computing, and social enterprise collaboration.

    He had not touched a computer until high school but then quickly found his passion. Jonathan holds a Bachelor's degree in Computer Science from Newbury College and a Master's degree in Computer Information Systems from Boston University, which he completed while working full time. He holds VMware certifications, including VCAP5-DCD, VCP5-DCV, VCA-Cloud, DCV, and WM.

    Jonathan has worked in enterprises and start-ups throughout his career and has become a self-defined jack of all trades, but he is most passion ate about virtualization and its community, and was honored as a vExpert 2013 for his contributions.

    You can find Jonathan on Twitter @jfrappier, and on his blog at www.virtxpert.com as well as at almost every Virtualization Technology User Group (VTUG) meet. He also supports the #vBrownBag podcast at professionalvmware.com.

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now