VMware vSphere Design Essentials

5 (1 reviews total)
By Puthiyavan Udayakumar
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Essentials of VMware vSphere

About this book

vSphere allows you to transform your IT infrastructure into a private cloud, then bridge it to public clouds on demand, delivering an IT infrastructure as an easily accessible service.

This book is a fast-paced guide that enables you to explore and harness the vast potential of VMware vSphere. The book begins by providing you with a rapid introduction to VMware vSphere architecture and the major considerations for VMware vSphere design. Beginning with the essentials of VMware vSphere, it will get you started with VMware ESXi host, cluster, vCenter and patterns that are required to be applied while designing your VMware vSphere. As you progress through the chapters, you will learn about analyzing the key components that are needed for a network.

By the end of the book, you will have also learned about the major factors influencing vCloud needs and have finalized the requirements for designing a vCloud.

Publication date:
June 2015


Chapter 1. Essentials of VMware vSphere

Thanks for choosing VMware vSphere Design Essentials, your companion in learning the fundamentals of designing VMware vSphere. We understand your mission to learn, apply, and reap the benefits of virtualization and to design VMware vSphere to its fullest extent using this book. Let's get started learning about VMware vSphere and its essentials.

VMware vSphere is a product developed by VMware, Inc. The company is located at Palo Alto, California, USA, and was started in 1998. It offers virtualization, cloud software, and services. VMware vSphere is a product that aims to provide x86 virtualization to renovate datacenters into streamlined cloud computing infrastructures, which in turn enables IT organizations to deliver consistent and elastic IT services.

vSphere virtualizes physical hardware and converts one single physical system into multiple VMs; thereby VMware vSphere reduces the space, cost, and complexity of managing systems in a datacenter. This book is not only for VMware architects but also for people who use vSphere on a daily basis. This book will help you understand how vSphere is designed and will help you to design your virtual infrastructure using VMware vSphere to its best potential. Also this book will help you to improve your skills; you will become well versed in designing best practices.

Designing VMware vSphere infrastructure will be a multipart subject. In this chapter, we'll provide an introduction to the VMware vSphere landscape, the design of vSphere itself, challenges and obstacles that were caused by virtual infrastructure due to poor design, and the way to overcome those challenges with structured principles and processes.

In this chapter, you will learn the following topics:

  • Introduction to the VMware vSphere landscape

  • Designing VMware vSphere

  • Challenges and obstacles faced with the virtual infrastructure

  • Designs that will accelerate solutions to resolve real-world obstacles

  • Values and procedures that need to be followed while designing VMware vSphere


Introducing the VMware vSphere landscape

VMware vSphere is built for infrastructure virtualization. The benefits of this product are as follows:

  • Virtualizing x86 systems

  • Virtualizing networks

  • Virtualizing storage

  • Built-in security and High Availability

  • Automated monitoring

The VMware vSphere landscape is formed by the following mandatory components. If the infrastructure is designed without any one of these components, it will result in issues such as poor performance, poor user experience, and applications not working. Let's take a look at the components of vSphere in the following table:




This provides a virtualization layer that contains computing, network, and storage resources of the ESXi host into several VMs.

We will see more information on designing the management layer in the upcoming chapters.

Management layer

This is nothing but a vCenter that provides a layer as a vital administration point for ESXi hosts associated on your network.

We will see more information on designing the management layer in the upcoming chapters.


This is nothing but a collection of virtual memory, virtual CPUs, and virtual network interface cards; all these components form vCompute.

We will see more information on designing the management layer in the upcoming chapters.


This links VMs to one other within ESXi host, establish the communication between VMs virtual NIC to the physical network, and along with that also provides a communication chancel services for VMkernel services (including NFS, iSCSI, vMotion)

We will see more information on designing vNetwork in the upcoming chapters.


This is nothing but an application interface layer, which in turn provides an abstraction layer to manage and modify physical storage during implementation.

We will see more information on designing vStorage in upcoming sections in this chapter.


This acts a data management point to organize all the configuration data for the VMware vSphere infrastructure.

We will see more information on designing databases in upcoming sections in this chapter.

Designing these components is highly critical for virtualization success. The following diagram illustrates the associations within each component:

You need to have understood component associations within VMware vSphere. As the next step, start designing essentials before we jump into designing each component. Let's get started with understanding the essentials of designing VMware vSphere. Designing is nothing but assembling and integrating VMware vSphere infrastructure components together to form the baseline for a virtualized datacenter. It has the following benefits:

  • Saves power consumption

  • Decreases the datacenter footprint and helps towards server consolidation

  • Fastest server provisioning

  • On-demand QA lab environments

  • Decreases hardware vendor dependency

  • Aids to move to the cloud

  • Greater savings and affordability

  • Superior security and High Availability


Designing VMware vSphere

Architecture design principles are usually developed by the VMware architect in concurrence with the enterprise CIO, Infrastructure Architecture Board, and other key business stakeholders.


From my experience, I would always urge you to have frequent meetings to observe functional requirements as much as possible. This will create a win-win situation for you and the requestor and show you how to get things done. Please follow your own approach, if it works.

Architecture design principles should be developed by the overall IT principles specific to the customer's demands, if they exist. If not, they should be selected to ensure positioning of IT strategies in line with business approaches. In nutshell, architect should aim to form an effective architecture principles that fulfills the infrastructure demands, following are high level principles that should be followed across any design:

  • Design mission and plans

  • Design strategic initiatives

  • External influencing factors

When you release a design to the customer, keep in mind that the design must have the following principles:

  • Understandable and robust

  • Complete and consistent

  • Stable and capable of accepting continuous requirement-based changes

  • Rational and controlled technical diversity

Without the preceding principles, I wouldn't recommend you to release your design to anyone even for peer review.

For every design, irrespective of the product that you are about to design, try the following approach; it should work well but if required I would recommend you make changes to the approach.

The following approach is called PPP, which will focus on people's requirements, the product's capacity, and the process that helps to bridge the gap between the product capacity and people requirements:

The preceding diagram illustrates three entities that should be considered while designing VMware vSphere infrastructure.


Please keep in mind that your design is just a product designed by a process that is based on people's needs.

In the end, using this unified framework will aid you in getting rid of any known risks and its implications.

Functional requirements should be meaningful; while designing, please make sure there is a meaning to your design. Selecting VMware vSphere from other competitors should not be a random pick, you should always list the benefits of VMware vSphere. Some of them are as follows:

  • Server consolidation and easy hardware changes

  • Dynamic provisioning of resources to your compute node

  • Templates, snapshots, vMotion, DRS, DPM, High Availability, fault tolerance, auto monitoring, and solutions for warnings and alerts

  • Virtual Desktop Infrastructure (VDI), building a disaster recovery site, fast deployments, and decommissions

The PPP framework

Let's explore the components that integrate to form the PPP framework. Always keep in mind that the design should consist of people, processes, and products that meet the unified functional requirements and performance benchmark. Always expect the unexpected. Without these metrics, your design is incomplete; PPP always retains its own decision metrics. What does it do, who does it, and how is it done? We will see the answers in the following diagrams:

The PPP Framework helps you to get started with requirements gathering, design vision, business architecture, infrastructure architecture, opportunities and solutions, migration planning, fixing the tone for implementing and design governance. The following table illustrates the essentials of the three-dimensional approach and the basic questions that are required to be answered before you start designing or documenting about designing, which will in turn help to understand the real requirements for a specific design:



Key components


Results of what?

In what hardware will the VM reside?

What kind of CPU is required?

What is the quantity of CPU, RAM, storage per host/VM?

What kind of storage is required?

What kind of network is required?

What are the standard applications that need to be rolled out?

What kind of power and cooling are required?

How much rack and floor space is demanded?


Results of who?

Who is responsible for infrastructure provisioning?

Who manages the data center and supplies the power?

Who is responsible for implementation of the hardware and software patches?

Who is responsible for storage and back up?

Who is responsible for security and hardware support?


Results of how?

How should we manage the virtual infrastructure?

How should we manage hosted VMs?

How should we provision VM on demand?

How should a DR site be active during a primary site failure?

How should we provision storage and backup?

How should we take snapshots of VMs?

How should we monitor and perform periodic health checks?

Before we start to apply the PPP framework on VMware vSphere, we will discuss the list of challenges and encounters faced on the virtual infrastructure.


List of challenges and encounters faced on the virtual infrastructure

In this section, we will see a list of challenges and encounters faced with virtual infrastructure due to the simple reason that we fail to capture the functional and non-functional demands of business users, or do not understand the fit-for-purpose concept:

  • Resource Estimate Misfire: If you underestimate the amount of memory required up-front, you could change the number of VMs you attempt to run on the VMware ESXi host hardware.

  • Resource unavailability: Without capacity management and configuration management, you cannot create dozens or hundreds of VMs on a single host. Some of the VMs could consume all resources, leaving other VMs unknown.

  • High utilization: An army of VMs can also throw workflows off-balance due to the complexities they can bring to provisioning and operational tasks.

  • Business continuity: Unlike a PC environment, VMs cannot be backed up to an actual hard drive. This is why 80 percent of IT professionals believe that virtualization backup is a great technological challenge.

  • Security: More than six out of ten IT professionals believe that data protection is a top technological challenge.

  • Backward compatibility: This is especially challenging for certain apps and systems that are dependent on legacy systems.

  • Monitoring performance: Unlike physical servers, you cannot monitor the performance of VMs with common hardware resources such as CPU, memory, and storage.

  • Restriction of licensing: Before you install software on virtual machines, read the license agreements; they might not support this; hence, by hosting on VMs, you might violate the agreement.

  • Sizing the database and mailbox: Proper sizing of databases and mailboxes is really critical to the organization's communication systems and for applications.

  • Poor design of storage and network: A poor storage design or a networking design resulting from a failure to properly involve the required teams within an organization is a sure-fire way to ensure that this design isn't successful.

Planning, designing, and positioning a virtualization-based infrastructure are really difficult tasks. There are sizable technical hurdles for administrators to jump, but often it's the challenge of getting everyone to pull in the same direction that ultimately slows a virtualization rollout. Let's explore the top 10 considerations that should be considered before starting to design a VMware virtualization and the best time to start. According to VMware experts, the right stage to start considering, is the beginning, which leads on to the following questions:

  • Why is the customer seeking to implement VMware vSphere?

  • What applications does the customer plan to deploy?

  • What objective does the customer hope to reach with the help of a VMware vSphere deployment?

  • What are the existing problems, business or technical, that the customer is trying to resolve?

Requirement gathering and documenting are the driving factors for virtualization; the objectives, problems and needs of the customer should be the first task to undertake before we can start designing. This is the beginning and translates into what we have called the design factors—requirements, constraints, risks, and assumptions. They are crucial to the success of any vSphere design. In the next section, you will learn the ways in which we can overcome the challenges and enforcements.


Designing accelerates the solution that resolves real-world obstacles

This section provides a step by step sequence and activity that is required to be followed in order to design a virtualization; this is a completely elastic method that best fulfills your infrastructure demands. The steps are obtainable in an ordered sequence as per the following diagram:


It's really difficult to build a virtual infrastructure if you don't know the target or requirements. Elicitation is the step where the requirements are first gathered from the customer. Many practices are available for gathering requirements. Each has a certain value in certain situations; you need manifold techniques to gain a complete picture from various sets of clients and stakeholders. Here's a look at some of the approaches you can take:

  • One-on-one meeting with IT leaders and top management sponsors for the project

  • Team meetings with the current team responsible for managing technical operations

  • Facilitated sessions, prototyping, initial engagement surveys, use cases, following people around, Request for Proposals (RFPs), brainstorming

Finally, at the end of requirement gathering, conduct workshops with all these reviews, lastly look for room for improvement. If all stakeholders in a session try to appraise the value and cost for each demands, at last artifacts becomes much more effective and cost-valuable. Hence, schedule periodic meetings to review and agree requirements:


Documentation helps to identify the current state of infrastructure and helps to identify inputs for our next stage in the analysis.


Research and collect data facts as far as possible before you start planning for design; since the analysis or research must be lightweight, it must also be less scrupulous. Best results come from considering user insights from the very start as input and giving the result to the design process.

In the early stages of the process, the discovery stage will help you identify new breaks and will describe the design in brief. VMware vExperts advise re-iterative ESXi and VM configuration testing before it is rolled out to the Proof of Concept (POC). In turn, this will help to inform decisions from the design phase to the final implementation. A usability problem can be corrected more swiftly and with less cost if it is identified at the design stage itself rather than at the support stage.

We will use the 4D-stage analysis process to display how we can fit in all the stages:

The preceding 4D stage analysis, as explained in the following table, aligns to the method that is required to be adopted in each stage:





Engage with the business and observe the requirements, in the context of demand and services.

Cognitive Map


Interpret requirements, rationalize, and verify business demands. This is a key input for the design for it to proceed to further stages.

Task and gap analysis


Key metrics need to be finalized with the help of cognitive map and analysis output, because the method we develop will be followed during the design phase.



Evaluate the prototype with the business to verify and refine the requirements and align the design towards an agreed solution.

Quantitative and qualitative

With this approach, we will be able to gain an insight into requirements and the output of this phase is an input to the planning phase. As the next step, let's learn about planning and its implications to the design phase.


The design considerations we made in final steps may make us to change the decisions which we made in the earlier steps, due to various thought clashes. Every alert challenges the potential requirement gathering, planning, and design, which will be a great challenge throughout the project planning.

We will come to design phase which meets best of our requirements, only after iterating through the stages as many times as required to include all of the thoughts within the manuscript. The following diagram illustrates the key technical metrics that are required to be a part of your planning technical artifacts:

Each phase of planning and its mission is listed in the following table:

Phases of planning

Key objectives

Identify VM resource requirements

Mission 1: Determine the workload resource requirements

Mission 2: Define the workload characterizations

Plan for VM configuration

Mission 1: Define the compute configuration

Mission 2: Define the network configuration

Mission 3: Define the storage configuration

Mission 4: Define the VM availability strategy

Mission 5: Define the VM types

Plan for cluster

Mission 1: Define the physical locations

Mission 2: Define the ESXi host cluster

Mission 3: Determine the cluster ESXi host members

Plan for ESXi hosts

Mission 1: Define the compute configuration

Mission 2: Define the network configuration

Mission 3: Define the storage configuration

Mission 4: Define the server virtualization host scale

Mission 5: Define the server virtualization host availability strategy

Plan for DRS and DPM

Mission 1: Define the priority configuration

Mission 2: Define the algorithm and calculate it

Mission 3: Define the threshold configuration

Mission 4: Define the balanced average CPU loads or reservations

Mission 5: Define the balanced average memory loads or reservations

Mission 6: Define resource pool reservations

Mission 7: Define an affinity rule

Plan for HA and FT

Mission 1: Define monitoring mechanisms for physical servers and VMs

Mission 2: Define server failure detection

Mission 3: Define migration and restart of VM Priority from failed ESXi host

Mission 4: Define the vLockstep technology for FT

Mission 5: Define the transparent failover

Mission 6: Define the component failures

Plan for VMware architecture

Mission 1: Define the maintenance domains

Mission 2: Define the physical fault domains Mission 3: Define the reserve capacity

Plan for architecture capability habits

Mission 1: Define the original SLA factors for storage and VMs

Mission 2: Define the original costs for storage and VMs

If you're looking for a tool that can do this, then the best tool to use (and one that VMware recommends) is VMware Capacity Planner. It is the right thing to start with.

VMware Capacity Planner is a capacity planning product that gathers comprehensive resource consumption data in assorted IT environments and associates it to industry standard position data to provide analysis and decision support modeling. The following are the key benefits of the product:

  • Increased efficiency with server union and volume optimization

  • Reduced complication through IT calibration and hardware restraint

  • Improved expectations with capacity consumption trends and virtualization targets

The output of data gathering from the requirements, analysis, and planning phases is a design phase input. This is really a key factor for your success. In the next section, let's explore the key requirements for designing in general and then we will map that to the streamlined process and principles.


Design essentials are what this book is all about. Let's get started by looking at the fundamentals. Any design, irrespective of the platform, should be enabled with factors such as balance, proximity, alignment, repetition, contrast, and space. These factors, in turn, should focus on the following:

  • Identifying design thoughts and encounters

  • Describing where to start with customers

  • Describing procedures for dealing with decision architects

  • Identifying if you've achieved design acceptance

  • Identifying what your framework should include

  • Identifying the phases of design

  • Identifying the risks associated with the discovery phase

  • Identifying the best practices that can fit the customer's needs.

  • Identifying the method that is capable of either scale-out or horizontal scaling

The preceding components will help you to attain the following deliverables that will help you to build the right solution document for small, medium, and enterprise businesses:

  • Design component and logical view

  • Design references architecture

  • Design sizing and scalability capacity

  • Design of ESXi host

  • Design of VMware vSphere Management Layer

  • Design of VMware vSphere Network Layer

  • Design of VMware vSphere Storage Layer


The values and procedures to be followed while designing VMware vSphere

Designing VMware vSphere is really challenging; to avoid any bottleneck, we need to learn and understand how it is really done by experienced architects and VMware itself. In the following section, we will discuss the values and procedures that need to be followed while designing VMware vSphere.

As you are aware, inputs for each design have to come from the PPP framework in order to achieve the desired success, including decision-influencing factors. This helps us to satisfy the functional requirements and performance benchmarks.

Start your design by focusing on the business drivers, and not the product features. The products could be the best in the world, but no good for your use case irrespective of any conditions. For example, if you have been asked to design your VMware vSphere-based Hadoop clusters, the driving factors for your design decision would not include fault tolerance. However, for a business-critical application, fault tolerance will be vital and, if that business-critical application needs more than one CPU, then we would not be able to use VMware vSphere Fault Tolerance to continue its uptime. On the design document, the feature looks good, but it doesn't work in the real infrastructure. The following diagram illustrates values of virtualization and its subcomponents:


As we make decisions that will form a VMware vSphere design, one value to be considered most is readiness.

Readiness is all about integrating different components together: uptime and system reliability, downtime, redundancy, and resiliency. In a nutshell, a mechanism that avoids crashes and maintains performance.

Values should have a close relationship with each other. With regard to the PPP framework of design, the value of readiness typically has the greatest effect on product decisions.

In some cases, the functional requirements explicitly call for readiness; for example, a functional and performance requirement may demand that the vSphere design must provide 99 percent readiness to meet any demand. In this case, readiness is explicitly noted by the requirement gathering and therefore must be incorporated into the design.

In some other cases, the functional requirements may not explicitly state readiness demands at 99 percent. In these cases, the designer should include an appropriate level of availability as per the projected target state.

To accommodate both cases in the design document, always come up with an assumption section. An assumption section can offer justification for the vSphere designer's decisions within the broader business framework of functional performance requirements, design consideration, and constraints. When readiness isn't explicitly stated, the designer can provide an assumption that the infrastructure will be made as ready as possible within the cost limitations of the statement of work.


Performance is often called for in the performance requirements, and it can affect decisions in the product and people phases. For the product phase, it can affect all manner of design decisions, starting from the type of the server's hardware to the kind of network storage devices planned. With regard to the performance demand, it's mostly seen as a Service Level Agreement (SLA) that expresses performance metrics, such as response times per request, transactions per second in the network, and the capacity to handle the maximum number of users.

If there is no performance requirement explicitly defined, the designer of a vSphere infrastructure should consider performance as a key component for its design decisions.

The KA key stage is to review and agree the performance metrics and make sure they have been documented on a low-level design, as well as ensuring that the specified components are validated against the gathered requirements. The key components that need to be considered and validated are as follows:

  • For hardware or CPU, the designer should consider options such as Hardware Assisted Computing Virtualization, Hardware Assisted I/O Memory Managed units Virtualization and Hardware Assisted Memory Managed units Virtualization.

  • For Network adapters, the designer should consider the following; such as Checksum Offload, TCP Segmentation Offload (TSO), the ability to handle high-memory DMA (that is, 64-bit DMA addresses), the ability to handle multiple Scatter Gather elements per Tx frame, Jumbo frames (JF), and Large Receive Offload (LRO). When using VXLAN, the NICs should support offload of encapsulated packets.

  • For memory, the designer should consider factors such as NUMA, paging size, memory overhead, and memory swapping.

  • For storage, the designer should consider options such as vSphere Flash Read Cache (vFRC), VMware vStorage APIs for Array Integration (VAAI), LUN Access Methods, virtual disk modes, linked clones, and virtual disk types.

  • For network, the designer should consider the following such as Network I/O Control (NetIOC), DirectPath I/O, Single Root I/O Virtualization (SR-IOV), SplitRx Mode, and Virtual Network Interrupt Coalescing.


The designer should consider that the management pane has a key component that should be documented in a design document. Manageability is a key factor that works on support and operations. As a part of the support, managing infrastructure is most essential; hence, manageability is integrated from various factors:

  • Reachability from one infrastructure environment to another environment, from one location to another location

  • Usability, scalability, and interoperability

  • Access, manipulation, scripting, and automating common administrative tasks

  • Obtaining statistics from guest operating systems

  • Extending the vSphere Client GUI to vCLI

  • Monitoring mechanisms to manage server hardware and storage

  • Performance monitoring mechanisms and obtaining historical data


Recovery after a disaster is a key design principle that should be considered. With traditional disaster recovery procedures, the IT team have to identify a way for budgets to support the solution and make decisions about exactly which systems will not be sheltered. This process made ease via virtualization and along with a arrival of disaster recovery offerings via private and public clouds. Resiliency services and business continuity services are now ease for administer to manage, in turn makes huge disaster recovery protection for all applications.

To protect critical data and systems, only a few tools are available in the market today, especially to query real-time data replication and failover. It is critical for vSphere designers to understand that these tools are required for the appropriate infrastructure, and it is very important for designers to know exactly which systems and data need to be protected along with the type of protection that they are demanded, defining the metrics become one of the main design essentials for vSphere.

To start with, the first key metric is the Recovery Point Objective (RPO). For any data protection tool, RPO defines how much data could be lost in the recovery procedure. In case a single disk drive in the RAID 5 array undergoes failure, then there is no associated data loss. This is called as RPO of zero. At worst case scenario is that the entire disk in an array undergoes failure. In this situation, if a business demands data restoration from the last good known tape backup, the RPO time for this would be 12 to 24 hours. Essential of defining RPO of VMs is highly demanding, along with an integrating of tools in the design document.

The next serious metric is Recovery Time Objective (RTO). Used along with RPO, RTO measures the time taken for the entire recovery process up until the time where the end user can reconnect to their applications.

For example, if a production server fails and reaches a state where the server should be reimaged using the same tape backup solution, the RTO could be hours or days. This is will depend on time taken to repair the existing hardware or build the new hardware, followed by installing the host, guest OS and followed by applications deployment time . Hence, integrating this information on your design document is essential.

Once recovery objectives such as RPO and RTO have been finalized, most organization discovers that a traditional tape backup alone is not enough to meet their objective of high availability for many critical applications, Therefore, many organization will implement integration of different solutions such as data replication and application high availability attached with guest OS virtualization.


Security is yet another key principle that has to be incorporated into virtualization design. VMware has its own product for security—VMware vShield Endpoint (VSE). VSE offers endpoint protection by command of magnitude and divests anti-threat agent processing inside VMs that reside on ESXi and safe virtual appliance brought by VMware partners. VSE improves amalgamation ratios, performance, rationalizes antivirus deployment, monitoring for threats, and make sure compliance by logging antivirus and anti-malware activities which are accomplished in the virtual infrastructure.

Virtualization security is a key component of design. While the IT team needs to implements its own security practices and security governance in the phase of virtualization, the clear impact is that security can be really advantageous. Virtualization improves security by assembly it more fluid and context-aware solution. Which means security is more precise to manage, and cost effective to deploy than traditional security software.

Virtualization security empowers datacenter admins with the authority of automation on provision VMs. These VMs are fully wrapped with security policies that follow desktops when users move across from one system to another system.

With the accurate processes and products, virtualization has the authority to make datacenters even more secure; hence they identify the right tools to protect VMware vSphere-based virtualizations.


Assumptions should be an important section in the design document; without the assumption section, the planning phase cannot be driven forward. Factors that need to be considered by designers are the following:

  • The existing infrastructure that can be used for the virtualization project

  • Application virtualization consolidation and compatibility assessment

  • List of firewall rules in place

  • Trained VMware-Certified resources to deploy the solution and support it further

  • Equipment that will be presented at a certain date

  • The organization has satisfactory network bandwidth

  • Server hardware that has to be separated between DMZ and internal servers

  • Identify suitable best practices associated with a proposed design

  • Subordinate a role to the material that needs to be composed

  • Stakeholders that will make a decision in the next meeting

  • In scope and out of scope that has to be reviewed and agreed on between the project sponsor and project supplier

If you design your capacity in such a way that your business is going to grow by 20 percent yearly, this growth will apply linearly to the ingesting of the available capacity in the datacenter. This can be categorized under assumptions.


Constraints are a key principle that should be considered on design essentials. This section will impose obstacles and limit your design decision; it can be a technical limitation, the actual cost of the project, or the choice of vendors. Here are some examples of factors that limit the design:

  • The project has to be finished in a very limited period

  • The project requires infrastructure to meet the timeline

  • The project budget is very limited

  • Skilled resources to execute the design are very limited

  • Any vendor support needs for apps, servers, storage, and networks are limited

  • Any other factors that are affecting the design decision

If you purchased a SAN 3 years ago for a file server consolidation project, you plan to use it for a virtualization project, and you do not find any information about those devices, this can be categorized under the constraints section and it is really a critical component for the project execution phase.


Risk management is a key principle that is required to be considered while designing VMware vSphere infrastructure. Identifying the risk factor very early will help you to identify and highlight problems hiding inside your virtualization design effort:

  • The major risk listed in the virtualization project is whether the project will be delivered on time and on budget

  • Availability of technically skilled resources to complete the project on time

  • Not enough network bandwidth to handle the initial load

  • Isolating the infrastructure form development, pre-production to production

For example, you might be in a situation where the IT Management does not provide the required approval for changing the network core to increase iSCSI traffic. This can be characterized under risks on your design principles.

There are eight values of design as an outcome of design decisions. There are multiple ways to fulfill the functional and performance requirements, but a vSphere designer must evaluate each of the following against these eight values:

  • Does the choice positively or negatively impact the readiness of the design?

  • What about the design's manageability or performance?

  • What about recoverability and security?

  • What about risks, constraints, and assumption associated with it?

These principles provide generic guidance and direction on the best way to meet the functional and performance requirements for a particular design.

Before we wrap up this chapter, we will look at a final section on the process of designing VMware vSphere with its essentials.

Procedures to be followed while designing VMware vSphere

Now that we've discussed the PPP framework of design and the value of design, it's time to discuss the procedure of design. In this section, we'll start with how we go about creating a VMware vSphere design. The following procedure illustrates the various processes that are required to be followed while creating a VMware vSphere design:


Discovery is the key, and first stage of your design. This element will help you to get the following questions answered:

  • What are the needs of business users?

  • Which of the services currently meet those needs?

  • How are users performing?

  • What industrial or policy-linked restraints might there be?

Before you start building a design you need to build up a blueprint of what the context for that design is. This means lots of end user research, and a close assessment of current infrastructure and policies, ethics, and business needs.

Requirement gathering

Let's get started with requirement gathering, which is an important part of any IT virtualization project. Understanding what those requirements will bring, is success to virtualization project. Shockingly it's an part that is frequently given far too little courtesy.

Numerous designs start with the greenest list of demands, where some of via verse, for those we need focus and avoid these bottleneck ,by producing a document of requirements. This requirement document will acts as bible for design phase. It will, in turn, provide the following benefits as well:

  • A brief functional requirement for design purposes.

  • A statement of key objectives—a prime points condition

  • A description of the infrastructure in which the virtualization will work

  • Information on major design constraints to meet the requirements

The context on the statement of requirements should be stable. Architect should not allow state of changes, which will relatively slow down the phase of design and so forth.

Upon finalization of statement of requirements, make sure the business and respective stakeholders sign up and agrees to it. Technical artifacts expectation should inline to statement of requirements. No deviation should be entrained.

Here are well-known rules that will you help you successfully complete your requirement gathering:

  • Never assume what we have is what our client wants for

  • Involve the appropriate stakeholder right from beginning

  • Review, define and agree the scope of work for the virtualization

  • Make sure that the functional, nonfunctional and operational requirements are specific, measurable and realistic

  • Create a crystal-clear, detailed requirement document and share it with all the stakeholders to gain their confidence on the virtualization project

  • Demonstrate your understanding of the business requirements with all stakeholders (again and again)

Reviewing the existing document

Today, many organizations invest time and effort in building their requirements prior to engaging suppliers and consultants. Organizations implementing VMware vSphere have fully documented their functional requirements. This documentation often has outlines stating the organization objective.

For example, perhaps the enterprise is implementing virtualization as part of a VDI/Shared Desktop virtualization initiative. In that case, some of the functional and performances requirement of the VMware vSphere environment can be a show-stopper. In your VDI project, an initial requirement may be that the vSphere infrastructure should automatically restart VMs in the event of an ESXi host failure. The moment you read the statement, you may want to use vSphere High Availability on your design document in order to meet the given performance requirement. Since you have planned to use VMware vSphere High Availability, implementation of clusters is required. This, in turn means you have to set up redundant management connections that distress the networking and storage design and so forth.

Another case. Let's say an enterprise is migrating to a new datacenter and a team that has compiled the number of applications that have to be migrated. From that documentation, we can better understand the application requirements and identify the functional and performance requirements required to be supported by the virtual infrastructure that is intended to be designed. Possibly, the application dashboard documentation indicates that the IOPS profile is mainly writes instead of reads. This is a key element for designing the storage.

Though reviewing the existing documentation will be helpful, it's unlikely that you'll find all the information required for your design. But it is really worthwhile to spend time in identifying what is already available; it will save your time bridging the gap.

Technical assessment

Technical assessment is a critical step between the planning and design of a virtualization project. It has three important modules—infrastructure assessment, business assessment, and operational assessment. The goal of the technical assessment is to inventory current infrastructure and identify virtualization candidates.

The key deliverables of this assessment will be as follows:

  • Baseline the list of servers, that are ideal candidates for virtualization

  • Baseline performance and utilization, which is very much essential for capacity planning

Data collection does not have the arrangement required for the virtual server farm design. Inventory data may encompass fault values and performance reports may have wrong data, because the monitored server was shut down or not reachable via the network. Moreover, performance reports extracted from servers having disparate configurations cannot be equated unless data is standardized. Indeed, we cannot compare processor utilization reports for servers with different types of processor.

This phase is predominantly interesting when the server landscape whose data is being analyzed contains a number of servers. For each server, many data facts are available, requirements will streamline the metrics that are required to be considered; however, for the designer it is worth considering the following tools for capacity planning and utilization measurements:

  • VMware Capacity Planner

  • Countless community-supplied health-check scripts

  • CiRBA and NetIQ PlateSpin Recon

After you've gathered the information required to determine the design's functional requirements, it's then required to assess the current infrastructure. Assessing the infrastructure fixes a couple of gaps and, to do that, use the gap analysis as per the customer's demand.

Design integration

Design integration is essential for the successful design of VMware vSphere. Integration of design can happen only if factors such as data architecture, business architecture, application architecture, and technology architecture are put together, as illustrated in the following diagram:

To build this type of architecture, it is always recommended to get hold of TOGAF, DMM, UML, BPMN, or any of the Enterprise Architecture frameworks to build the design:

To be specific, with regard to technology architecture, always remember VMware vSphere should have a component model with components such as management layer architecture, network layer architecture, and storage layer architecture. Furthermore, it should integrate further with the cloud and SOA on demand.



In this chapter, we discussed the VMware vSphere landscape, designing VMware vSphere, and a list of challenges and encounters faced on the virtual infrastructure. Designing accelerates the solutions that resolve real-world obstacles, values, and procedures that need to be followed while designing VMware vSphere.

In the next chapter, you will learn about designing essentials for the management layer, which is, designing the VMware ESXi host, cluster, and vCenter.

About the Author

  • Puthiyavan Udayakumar

    Puthiyavan Udayakumar has more than 8 years of IT experience and has expertise in areas such as Citrix, VMware, Microsoft products, and Apache CloudStack. He has extensive experience in the field of designing and implementing virtualization solutions using various Citrix, VMware, and Microsoft products. He is an IBM Certified Solution Architect and a Citrix Certified Enterprise Engineer and has more than 16 certifications in infrastructure products. He has authored Getting Started with Citrix CloudPortal, Getting Started with Citrix® Provisioning Services 7.0 and VMware vSphere Network Virtualization Recipe Book. He holds a master's degree in science with a specialization in system software from the Birla Institute of Technology and Science, Pilani. He also has a bachelor's degree in engineering from SKR Engineering College, affiliated to Anna University, and has received a national award from the Indian Society for Technical Education. He has presented various research papers that follow the IEEE pattern at more than 15 national and international conferences, including IADIS (held in Dublin, Ireland).

    Browse publications by this author

Latest Reviews

(1 reviews total)
VMware vSphere Design Essentials
Unlock this book and the full library FREE for 7 days
Start now