Learning VMware vSphere

Chapter 1. An Introduction to Server Virtualization Using VMware

Let's go back to a time when there wasn't a concept of server virtualization. We had data centers running a large number of machines; most of them were bought to run an application or a set of services. All those servers had enough CPU, memory, and storage capacity to host the application or the services that were running on it. The amount of compute and storage resources depended on what the application or the service would need during its peak load. However, the catch here is that not all servers execute peak load all the time. Research shows that more than 90% of hardware resources remain under-utilized. That is a huge number in terms of resource wastage. Running more than one application or service for the business always meant that there was a demand for additional hardware resources. Such a demand contributed to other factors such as power consumption, investment in cooling solutions, hardware maintenance, and the real estate space required to host all the hardware.

Now, a possible solution an administrator could have fantasized about would be to find a way to somehow magically connect all these servers together and present it as a large pool of resources to the applications or services. If that were possible, then you would probably be renting out 90% of your resources, that you have already invested in, to someone else to run their applications and you are paid for that service. Or, if you were in the planning phase of a new infrastructure, you could reduce the amount of server hardware needed for hosting the services. Unfortunately, such a conglomeration was far from reality due to two main reasons, the first one being the physical boundaries that separate these hardware resources and the second one being that not all services could run alongside each other without running into a conflict, affecting both the services. This is where the concept of server virtualization did its magic, on its introduction, like never perceived before.

In this chapter, we will learn the following:

The magic of server virtualization
What is a hypervisor?
What is a virtual machine?
An introduction to VMware vSphere

The magic of server virtualization

Server virtualization lets you run multiple conventional operating systems such as Windows and Linux, isolated from each other but sharing the same physical server hardware. This is achieved by creating an abstraction layer between the server hardware and the operating systems that run on them. The abstraction layer acts as the interface and the resource management layer, which enables the sharing of the resources between the operating systems:

The operating systems remain completely unaware of the fact that they are running inside a virtual machine and that there are other operating systems running on the same hardware. This is because each of these operating systems live in their own containers, which isolates them from other operating systems. This should not be confused with application containers such as Docker or Rocket.

Although the server's hardware resources are shared, server virtualization requires you to assign resources to the operating system containers. The resources are assigned in terms of the number of virtual CPUs, amount of memory, amount of storage, and virtual network cards.

Server virtualization is enabled by a piece of code called the hypervisor, and the resource-assigned container for running the operating systems is called a virtual machine. We will discuss more on the concepts of hypervisors and virtual machines later in this chapter.

The benefits of server virtualization

Before we delve into the further details of virtualization, it is important to understand the benefits of virtualization:

Cost, energy, and real estate savings: Virtualizing reduces the number of hardware servers required to host your applications. This is due to the fact that you no longer would need to buy separate physical servers to host conflicting applications. Instead, you could run them on separate virtual machines running on the same server hardware. A lesser number of physical servers will mean reduced power requirements and smaller data center real estate as well.
Easier management: Unlike managing physical machines separately, you now can manage all your virtual machines from a single management interface. This greatly reduces the administrative effort, which would otherwise be required to manage a large number of physical machines.
Easier maintenance: Performing hardware maintenance no longer requires application downtime since virtual machines can be migrated in their live state from the server which needs maintenance to another working server.

Although there are several benefits, we have covered the most salient ones in this section. The Economics of Virtualization, Moving toward an application-based Cost Mode, WHITE PAPER is a great read to understand the benefits that virtualization offers.

Note

For more information, visit https://www.vmware.com/files/pdf/Virtualization-application-based-cost-model-WP-EN.pdf.

What is a hypervisor?

A hypervisor is a piece of software usually not very big in terms of compute or storage footprint, which makes server virtualization possible. It forms an abstraction layer between the server's hardware resources and the operating system containers. There are two types of hypervisors defining two different types of approaches:

Type 1 hypervisor (bare-metal hypervisor)
Type 2 hypervisor (hosted hypervisor)

A type 1 hypervisor is installed directly on the server hardware as you would install an operating system on any hardware. Hence it is referred to as a bare-metal hypervisor. It interfaces directly with the hardware. This empowers it to effectively manage sharing of the server hardware resources, among the virtual machines:

Examples of a type 1 hypervisor are VMware ESXi, Microsoft Hyper-V, and Citrix XenServer.

A type 2 hypervisor cannot be installed directly on server hardware. It is installed as a piece of software on any of the supported conventional operating systems such as Apple OS X, Microsoft Windows, or Linux. It leverages the underlying operating systems ability for resource management. The performance of a type 2 hypervisor is considered to be lower than that of a type 1 hypervisor. This is due to the fact that it cannot directly interface or manage the server's hardware resources:

Examples of a type 2 hypervisor include VMware Workstation, VMware Fusion, Parallels Desktop, and Virtual Box.

VMware ESX hypervisor

ESX is VMware's proprietary hypervisor. It is the foundation that enables virtualization of your data center.

VMware released their first hypervisor in the year 2001 and it was simply called ESX. They did release a second version, ESX 1.1, the same year and ESX 1.5 in 2002. After that there were several major version releases, ESX 2.0 in 2003 and ESX 2.5 in 2004. In 2006 they released VMware Infrastructure 3, which was their first product suite that included ESX 3.0, followed by several product suite releases - VMware Infrastructure 3.5, VMware vSphere 4.0 in 2009, vSphere 4.1 in 2010, vSphere 5.0 in 2011, vSphere 5.1 in 2012, vSphere 5.5 in 2013, and vSphere 6 in 2015. All of the releases have seen new features and improvements that continue to revolutionize our modern day data centers.

Before the release of VMware ESX 3.5, VMware had a Linux-based Service Console packaged along with the hypervisor. The Service Console was VMware's Linux-based console operating system, which provided a management interface to the ESX server. Meaning that if you were to assign an IP address to the ESX server, then it was the Service Console that had the IP address configured on it. It was the sole management interface. It was also used as a command-line workspace and a platform to load third-party management agents. Since it was based on a Linux operating system, the Service Console brought with it all the bugs, security issues which that particular Linux release had. This is not to say that Linux is buggy, but it did bring in the most common bugs that you see in a conventional operating system into the ESXi package. VMware had to periodically release security fixes for the Service Console component.

With the release of version 3.5, VMware also released a hypervisor-only model. The hypervisor-only model no longer had the Linux-based Service Console packaged with it, making it considerably small in terms of both compute and storage footprint. It was small enough to be embedded into the server motherboards, by storing the ESXi in flash storage chips. It also allowed ESXi to be loaded onto a USB bootable device. One of the prime advantages of ESXi was that it exposed very little surface area for security attacks. VMware called the ESX with Service Console ESX and the hypervisor-only model, ESXi. The ESX version with the Service Console was commonly referred to as ESX Classic and the hypervisor-only model was embedded.

VMware hypervisor models

VMware's type-1 hypervisor or VMKernel had two different models. One of them is the older ESX classic model and the other is a subsequent hypervisor-only model (ESXi).

Although the ESX Classic model had the same VMKernel component, it also used an RHEL-based console operating system that ran in a privileged mode enabling the management of ESX. It was primarily used to provide a command-line interface for ESX, but was also used to run host management agents, third-party agents like that of a hardware monitoring or a system management agent, backup agents. VMware no longer makes the classic model of ESX, because it posed a larger surface area for security attacks. VMware had to frequently release patches to secure the console operating system, whilst only a few number of patches were required for the actual hypervisor component-VMKernel. The presence of the console operating system also meant a larger compute and storage footprint for ESX:

The ESX Hypervisor-only model (ESXi) does not have the console operating system, making it small enough to be embedded on motherboards or held in a USB thumb drive. And more importantly, it is more secure as it only exposed a very small surface area for security attacks. ESXi was first introduced with the release of ESX 3.5. It then had both the ESX classic and ESXi versions available. Starting with vSphere 5, VMware no longer makes the ESX classic version:

With ESXi, most of the functionalities that were available via agents running at the Console OS, have now been replaced with supporting frameworks built into VMKernel, making those functionalities agentless.

What is a virtual machine?

A virtual machine is a software construct that acts as a container for installing and running conventional operating systems on a server hardware managed by a hypervisor. It is an isolation boundary between the operating systems running on the shared hardware.

An operating system running on a virtual machine is completely unaware of the fact that it is indeed running on a virtual machine and resources assigned to it are also shared among other virtual machines. It assumes ownership of every resource that is assigned to it. Managing the sharing of resources among virtual machines is the duty of the hypervisor. The performance of the virtual machine is dependent on the hypervisor's ability to manage the shared resources.

When a virtual machine is created, it is assigned resources such as the CPU, memory, network interface, and storage. These resources are slices from a larger pool of resources that the server hardware can provide.

What makes up a virtual machine?

Now that we know the purpose of virtual machines, it is important to understand what components make up a virtual machine. Much like a physical machine, a virtual machine also has different components required for it to host a conventional operating system. The only difference being that the components and devices that become part of a virtual machine are behind an abstraction layer and hence don't have direct access to the hardware. Instead, every component such as the CPU, memory, and hard disks are slices from the physical server resources available. The operating system running on the virtual machine has an impression that it is running on physical hardware; indeed it is, but only the portion of the resources assigned to the virtual machine are exposed to the operating system:

Virtual Machine Monitor

From the previous sections, we have a brief idea as to what components make up a virtual machine. We know that it is an isolation container to run an operating system and its code without intervening with any of the other operating systems running on the same server hardware.

However, what enables this isolation? Who manages the resources for each of the virtual machines? You might already have an answer in mind, the VMKernel. Of course, it is the VMKernel, but VMKernel has several subfunctions. The kernel component that enables the concept of a virtual machine is called the Virtual Machine Monitor (VMM). Every virtual machine has an associated VMM providing virtual BIOS, virtual memory management, and other virtual devices.

The VMM has the following functions:

Processor virtualization
Memory virtualization
I/O virtualization

Processor virtualization

Every x86 operating system is coded to run directly on hardware (bare metal), which means that the operating system will run in the ring with the highest privilege, Ring 0:

Anything that runs at Ring 0 will have direct access to the x86 processor hardware. Now, the challenge is the placement of the VMM. Much like an x86 operating system kernel, the VMM also needs to run at a privilege level that has direct access to the processor hardware. VMware achieved full virtualization by using BT and DE techniques or Hardware-assisted Virtualization.

Binary Translation (BT) and Direct Execution (DE)

Binary Translation (BT) translates the privileged instructions from the guest operating system and then executes it on the processor.

Every operating system has two types of instructions-normal instructions such as arithmetic instructions and privileged instructions such as initiating an I/O or system calls. System calls are nothing but a method to call a privileged instruction, which is hidden from the user mode.

When executing a user's program or application code, the processor goes about doing its job by executing the normal instructions in the user mode (Ring 1, Ring 2, and Ring 3).

During the execution, if the processor encounters a privileged instruction such as initiating an I/O or a system call, it generates a trap indicating an exception and would need to switch to the kernel mode. Switching to kernel mode is nothing but handing over the execution to the operating system's kernel running at Ring 0. A kernel that runs at Ring 0 can execute every machine instruction and reference every memory location.

Note

What is a trap?

A trap is generated by the CPU indicating that it has encountered a condition which it cannot handle and requires assistance from the operating system. Traps are used to invoke a system call.

Since x86 wasn't designed with virtualization in mind, not every instruction will have a corresponding trap facility. A trap is an operating system functionality that captures an exception and passes the control over to the operating system kernel, to be executed at Ring 0.

Full virtualization using BT and DE requires the VMM to run at Ring 0 and the guest operating system at Ring 1:

Since the x86 operating systems are not written to run at Ring 1, every privileged instruction that is handed over to it will now have to be translated and executed by the VMM, running at Ring 0.

The dilemma here is that not every x86 OS instruction will have a trap facility. This is where binary translation does its job. It doesn't wait for the processor to encounter an exception and generate a trap. Instead, it captures and reviews the instructions. On encountering an exception, it emulates a trap and takes control over the execution of that instruction.

Direct Execution (DE) is used to send the user mode instructions directly to the processor. Although the guest OS is now placed at Ring 1, it is still at that level with a much higher privilege than the user mode instructions. Hence there is no need to translate the user mode instructions, rather they can be sent directly to the processor.

Hardware-assisted Virtualization

Both Intel and AMD have added enhancements to their processor families to assist virtualization:

Intel VT-x
AMD-V

These enhancements allow VMM to run in a new higher-privileged mode than Ring 0.

With Hardware-assisted Virtualization, privileged and sensitive instructions encountered can now be directly send to the VMM. Intel VT-x or AMD-V features should be enabled in BIOS of an ESXi host, to be able to run 64-bit virtual machines on it.

Memory virtualization

Like with the processor resources, the server's memory resource should also be shared among the virtual machines.

The processor has a mechanism to access every memory bit on a memory module by addressing those memory locations using physical addresses. The operating system maintains another contiguous address space called the virtual addresses for the processes that run on them. Every time a process tries to access memory, it uses the virtual address for that memory location. The operating system will then have to translate the virtual address to a physical address:

Now, when we throw a virtual machine into the mix, things take a different turn. All conventional operating systems that will be installed on a virtual machine have a memory management technique similar to what was alluded to in the previous paragraph. But since the whole idea behind virtualization is to let multiple such virtual machines, there has to be a mechanism to manage physical memory access or allocation to these virtual machines. On an ESXi host, the VMKernel does all the resource management. In this case, it has to find a way to manage the physical memory. It does so by adding another memory management layer called the machine address space:

Now, when a process running inside of a guest operating system tries to access a memory location, it uses the virtual address space to do so. The virtual address requested will then have to translate to a physical address as seen by the operating system. The operating system will then have to translate the physical address to a machine address. The machine address eventually hits the physical memory. If this procedure were to be followed for every memory access, it would add a considerable overhead. Memory virtualization addresses this problem, by providing a mechanism to directly map the guest operating system's virtual address space to the machine address space by maintaining Shadow page tables.

Hardware-assisted memory virtualization eliminates the need for Shadow page tables by providing a mechanism to map the guest operating system's physical address space to the VMKernel machine address space.

Hardware-assisted memory virtualization technologies

The following are the examples of Hardware-assisted memory virtualization technologies:

Intel's Extended Page Tables (EPT).
AMD's Rapid Virtualization Index (RVI) or Nested Page Tables (NPT). Both RVI and NPT are different names for the same AMD MMU virtualization technology.

Note

For more information on how hardware-assisted memory virtualization works refer to the Performance Best Practices for vSphere 5.5: http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf

I/O virtualization

I/O devices such as physical network interface cards and SCSI controllers will have to be made available to the virtual machines. But it wouldn't make sense if we allowed a virtual machine to own or control a device. If done so, it wouldn't allow other virtual machines to use the same resource. So, there is a compelling reason to virtualize I/O resources as well.

I/O virtualization is achieved by presenting emulated virtual devices or paravirtualized devices to the virtual machines. For emulated devices like that of an e1000 virtual network interface card, the guest operating system needs to have the required driver. For paravirtualized devices such as the VMXNET series of network interface cards you will need drivers supplied with VMware Tools. The driver corresponding to a device will interact with the I/O virtualization stack of VMkernel.

An introduction to VMware vSphere

VMware vSphere is a suite of core infrastructure solutions that help manage and monitor a virtual data center. The term vSphere was coined by VMware as a new name for their flagship virtual infrastructure in the year 2009 with the release of VMware Virtual Infrastructure 4. All the previous releases were called Virtual Infrastructure 3.x or 3.5 or 2.5, and backwards. The most recent version being vSphere 6 is the sixth generation of VMware's vSphere product line. They are the most feature rich and probably the only virtualization suite on the market covering every aspect of the virtual infrastructure with their own products or solutions.

So what really makes up vSphere? vSphere is basically a set of software solutions which include the hypervisor (ESXi), the vCenter server, and its plugins, supporting databases and host management agents. The hypervisors create a platform to run virtual machines and the vCenter forms the management layer. vCenter enables the creation of virtual data centers. Every other solution will interface and interact with the vCenter to manage or utilize the virtual data center. Having said that, VMware does offer APIs which allow third-party software developers to build tools that help manage platforms or leverage the management layer formed by the vCenter servers in an environment.

However, there are several components, tools, and features that fall under the umbrella of the vSphere suite. Not all components are within the scope of this book, but we will make an effort to include their relevance wherever possible. Most of the components are covered in depth in different chapters, but it is critical to have a brief understanding of these components before we learn about them in detail.

We will go through a very basic introduction of the following components and features.

vSphere ESXi

If you have read through the chapter up to this point then you will already have an understanding of what ESXi is. With the latest version, ESXi 6.0, there are a few scalability and a number of security enhancements.

Each ESXi 6.0 host can now support up to 480 logical CPUs, 12 terabytes of memory, and 1024 virtual machines. Let's compare this with some of the earlier versions of the ESXi hypervisor:

Limits	ESXi 6.0	ESXi 5.5	ESXi 5.1	ESXi 5.0	ESXi 4.1	ESXi 4.0
Number of logical CPUs per ESXi host	480	320	160	160	160	64
Amount of memory per ESXi host	12 TB	4TB	2TB	2TB	ITB	ITB
Number of virtual machines per ESXi host	1024	512	512	512	320	320

There are a number of security enhancements with the new version, and these include:

Managing the local accounts on an ESXi host either via vCenter or using new ESXCLI commands. With the earlier versions the local account management was performed via a direct vSphere Client connection to the ESXi host or using the Linux-like user management commands from the ESXi console.
New host advanced system settings to manage account lockout and password complexity policies.
Better auditability. User information in the logs for all actions initiated from the vCenter will now include the actual vCenter username along with vxpuser.
There are two different lockdown modes with the release of ESXi 6.0-Normal mode and Strict mode.
Enhanced graphics performance for VMware Horizon virtual desktops by leveraging NVIDIA GRID^TM technology.

VMware vCenter Server

In the previous sections of this chapter, we learnt about ESXi and virtual machines. In a large infrastructure, these entities need to be centrally managed. The central management is achieved using VMware vCenter Server. It comes in the form of a Windows installable program and also as a Linux-based virtual appliance. Without the vCenter server, you cannot cluster the ESXi hosts, which is essential for the enablement of the VMware features such as vSphere HA, vSphere DRS, and vSphere DPM. Also, every other management solution that is out there will need to interface with the vCenter Server by means of a plugin.

vSphere desktop and web clients

Currently, there are two types of client available from VMware that can be used to connect and manage your vSphere infrastructure. One of them is a desktop client which can only be installed on a Windows machine. It can be used to connect directly to an ESXi host or a vCenter Server. This form of the client will reach its end of life very soon as VMware will transition every GUI action to be performed through their web client. The desktop client is C# based and it is currently available only for backward compatibility and to support a few plugins which haven't been completely transitioned to the vSphere Web Client. Unlike the desktop client, the vSphere Web Client is a server component installed and configured on a machine and the users willing to connect will rely on their web browsers to connect the web client server to access the vCenter GUI. The most critical difference is that the vSphere Web Client cannot be used to connect to an ESXi host directly. You need to rely on the vSphere C# based desktop client for that, and it is one of many reasons why the desktop client is still around.

vRealize Orchestrator

VMware vRealize Orchestrator, also known as the vCenter Orchestrator, is a GUI-based process automation tool that is installed along with your vCenter Server. It is primarily used to create workflows to automate repeatable IT processes. It has a plug-in framework which can be used by other solutions to perform actions. The vCenter Server, vRealize Automation, VROPS, VCM, and tools that can leverage the Orchestrator to perform actions.

vSphere Update Manager

It becomes necessary to upgrade or patch your vSphere environment to maintain a reliable platform for your virtual machines. Although the ESXi hosts can be patched or upgraded manually it becomes a very tedious process and would require many man-hours to perform the activity in a large environment. This is where VMware vSphere Update Manager (VUM) comes in handy. It provides a mechanism to patch and upgrade the ESXi hosts with reduced manual intervention. It can also be used to upgrade or patch third-party products such as the Cisco Nexus 1,000V.

VMware Power CLI

VMware Power CLI is a set of modules or snap-ins which include cmdlets based on Microsoft Power Shell. It is used as a scripting tool for managing or automating most of the vSphere actions. The latest version, 6.0, has more than 400 cmdlets for both vSphere and vCloud environments.

VMware VROPS

VMware vRealize Operations Manager (VROPS) is an infrastructure monitoring solution. It does provide greater insights into the performance, capacity, and health characteristics of your vSphere environment. It can present information in the form of dashboards, it can generate smart alerts, and can perform predictive analysis. It comes packaged with a vCenter plugin, but you can install several other third-party plugins to let VROPS gather information from other components as well. For instance, there are adapters for EMC Symmetrix, VNX storage systems, and many more.

vSphere Data Protection

vSphere Data Protection (VDP) is an EMC Avamar-based backup and recovery solution from VMware Inc. It is available in the form, a Linux virtual appliance and can support up to 8 terabytes of de-duplicated backup data per appliance and up to 20 such virtual appliances can be associated with a single vCenter Server.

vShield Endpoint

VMware vShield Endpoint is a security framework from VMware which enables hosting the load of performing antivirus or antimalware analysis on virtual machines onto a dedicated appliance. The framework utilizes a thin-agent included with VMware Tools and a heuristics engine running on a separate appliance provided by the security vendor. Every ESXi host will run such an appliance for the virtual machines running on it.

VMware vMotion and Storage vMotion

VMware vMotion will let you migrate the live state of a powered-on virtual machine from one ESXi host to another without affecting any of the applications or its services running on it. Whilst Storage vMotion can relocate all the files backing the virtual machine from one data store to another and also migrate its live state from one host to another, or it can migrate only the files backing the virtual machine and leave the live state on the same host.

vSphere High Availability

VMware vSphere High Availability (HA) is a functionality that is used to configure a cluster of ESXi hosts to respond to an unplanned downtime event and ensure the availability of the virtual machines that were running on them, with very minimal downtime possible. It has the ability to monitor the guest operating systems and the applications running inside of a virtual machine and then decide to restart the affected virtual machine in an effort to reduce the downtime of a service due to an affected guest operating system hosting the service or a nonresponsive application corresponding to the service. It is important to understand that even though HA is configured on a cluster of ESXi hosts, it only provides high availability for the virtual machines and not for the hosts. It cannot start up or restart an affected ESXi host.

vSphere Fault Tolerance

VMware vSphere Fault Tolerance (FT) is used to enable continuous availability of a virtual machine with zero downtime, maintaining an identical copy of the virtual machine in lock-step mode. We will learn more about this, in Chapter 8, Virtual Machine Concepts and Management. Unlike vSphere HA, FT is enabled on individual virtual machines. Although, FT had imposed a lot of restrictions on the scalability and the actions that can be performed on an FT-enabled virtual machine with the earlier versions of vSphere, with vSphere 6, it has been vastly improved and most of the restrictions don't exist anymore:

Features	vSphere 6.0 FT	vSphere 5.5 FT
Number of vCPUs	4-vCPU SMP	1-vCPU
Max. memory on the VM	64 GB	64 GB
Sync technology	Fast checkpointing	Record and replay
Virtual machine snapshots	Yes	No
VMDK types	All types	Eager-zeroed thick only

vSphere Distributed Resource Scheduler and Storage Distributed Resource Scheduler

VMware vSphere Distributed Resource Scheduler (DRS) is a series of algorithms devised to manage an aggregated pool of computing resources and distribute virtual machines among the ESXi hosts in a cluster in an effort to reduce any resource imbalance in the cluster. It also helps in reducing the power consumption in the data center using DRS's power management feature known as Distributed Power Management (DPM). VMware DPM can help reduce the energy consumption of a data center by vacating VMs from an underutilized host and putting that host in a power-off state.

Unlike DRS, which manages the compute resources, Storage DRS manages the storage resources. It is a mechanism to balance space utilization and the I/O load on data stores in a data store cluster by migrating (using Storage vMotion) the VMs. Storage DRS can only be enabled on a data store cluster. It also influences the initial placement of the VMs on the data stores, by generating placement recommendations. vSphere Storage DRS requires Enterprise Plus licensing.

Tip

To understand how the vSphere licensing editions compare refer to: https://www.vmware.com/products/vsphere/compare

vSphere Storage I/O Control and Network I/O Control

VMware vSphere Storage I/O Control (SIOC) is used to throttle the VMkernel device queue depth of a LUN, based on the shares set on the virtual machine disks contending for I/O bandwidth. SIOC can only be enabled on data stores (FC/ISCSI/NFS) and not on RDMs. It cannot be enabled on data stores with multiple extents. In this book, you will learn how to enable SIOC on a data store.

VMware vSphere Network I/O Control (NIOC) enables use and creation of Network Resource Pools. Much like with the compute resources of an ESXi cluster, you can use resource pools on a vSphere Distributed Switch (VDS) to configure Shares, Bandwidth Limitation, and Quality of Service (QoS) values. Such resource pools are referred to as Network Resource Pools (NRP). There are both System Defined and User Defined NRPs.

Tip

Both SIOC and NIOC requires vSphere Enterprise Plus licensing.

vSphere Standard Switch and Distributed Virtual Switches

VMware vSphere Standard Switch (vSwitch) is a software switching construct (in other words, a software-based network switch) local to each ESXi host. It provides a network infrastructure for the virtual machines running on that host. Unlike a physical switch, a vSphere Standard Switch is not a managed switch. It doesn't learn MAC addresses to build a MAC table, but it does know the MAC addresses of the virtual machine vNICs connected to it.

Unlike the standard switch, the vSphere Distributed Switch (VDS) spans across multiple ESXi hosts. It is not locally managed at the ESXi host. It requires VMware vCenter Server for configuration and management, though VDS is only available with the vSphere Enterprise Plus license. It has a control plane which resides at the vCenter Server and a data plane which resides on an ESXi host that is connected to the VDS.

vSphere Virtual Symmetric Multiprocessing

VMware vSphere Virtual Symmetric Multiprocessing (SMP) enables a virtual machine to use more than one logical processor simultaneously.

VMware Virtual Machine File System

Virtual Machine File System (VMFS) is VMware's proprietary cluster filesystem that can be used to format block storage units presented to an ESXi host. VMFS will let more than one host have simultaneous read/write access to the volume. To make sure that a virtual machine or its files are not simultaneously accessed by more than one ESXi host, VMFS uses an on-disk locking mechanism called distributed locking. The current version of VMFS is 5.

VMware Virtual Volumes

Virtual Volumes (VVols) is a newly introduced concept with vSphere 6.0. It is not intended to replace VMFS, but to take advantage of the hardware capabilities of the storage system. It requires a supported vSphere API for Storage Awareness (VASA) provider for its functioning. It is not a filesystem by any means. It is only a method to encapsulate files, backing a virtual machine into virtual volumes, and these are created automatically when you create or modify a virtual machine. ESXi does not have direct control over the VVols created, instead it interacts with a Protocol Endpoint, which again is provided by the storage vendor.

vSphere Storage APIs

VMware vSphere Storage API is an application programming interface framework from VMware that enables the storage and backup software vendors to enable or enhance integration with vSphere. The vSphere Storage APIs-Data Protection (VADP) is a framework that enables backup vendors to create backup and recovery solutions that integrate with vSphere. The vSphere Storage APIs-Storage Awareness (VASA) enables storage vendors to create storage providers which become an interface for vCenter to gather storage characteristics for the LUNs presented to the ESXi hosts. The vSphere Storage APIs-Array Integration (VAAI) enables ESXi to offload certain storage operations to a supported storage array. For instance, the process of zeroing the blocks of an eager-zeroed thick VMDK during its creation can be offloaded to the array to speed up the process. The availability of these APIs is dependent of the type of license in use. So, when you are designing an environment for performance it is important to understand what APIs are available with which VMware license editions.

VMware Virtual SAN

VMware Virtual SAN is a hyper-converged storage architecture that enables creating a shared storage platform using the local storage on the participating ESXi hosts. Since this ability is built into the hypervisor, there is no requirement to deploy appliances. All the management is from the vCenter Server. VSAN supports two types of configuration, an all-flash architecture and a hybrid architecture. In a hybrid-architecture, SSD and magnetic HDDs are mixed together to form the storage layer. The SSDs will be used for caching purposes to increase performance. In an all-flash architecture, both caching and storage are done on SDDs, hence delivering a very high performance storage platform.

Storage Thin Provisioning

vSphere Storage Thin Provisioning enables the creation of Virtual Machine Disks (VMDKs) that consume the space required for the data in it and not the actual size of the VMDK. Meaning, if the VMDK is of the size 50GB, but the data in it is only 15 GB, then only 15 GB worth of storage space is consumed from the data store. It is beneficial because not every disk created is fully consumed leading to wastage of storage space. Thin provisioning helps in over-allocation, but requires better reporting to manage the consumption of the storage resources.

vSphere Flash Read Cache

Flash storage (Solid State Disks-SSDs) disks offer higher I/O performance when comparted to the magnetic disks. Unfortunately, SSDs are far more expensive than the regular hard disks. With the vSphere Flash Read Cache mechanism, you can configure the available local SDD storage to act as a cache for virtual machines to use. VMkernel handles the assignment and allocation of the cache.

vSphere Content Library

With vSphere 6, VMware introduced a new feature called the Content Library. It is used to store templates and other files that can be shared across infrastructures, and it is backed by a data store. They can be local to a vCenter, published to be subscribed, or subscribed from a published library.

vSphere Auto Deploy

vSphere Auto Deploy is a web server component, which once configured can be used to quickly provision a large number of the ESXi hosts without the need to use the ESXi installation image to perform an installation on the physical machine. It can also be used to perform the upgrade or patching of the ESXi hosts without the need for VUM.

vSphere Host Profiles

A VMware vSphere Host Profile is a configuration template that is created from existing ESXi hosts. It could only be created using the vCenter GUI. Host Profiles can be attached to other ESXi hosts managed by the vCenter and can be used to track configuration changes by monitoring compliance of the attached hosts, or it can even be used to apply configuration changes to a large number of hosts, greatly reducing the amount of manual work which would otherwise be required.

vSphere Replication

vSphere Replication is a replication engine that can be leveraged to configure replication on individual virtual machines. It can replicate a virtual machine and its disks from one location to another without the need to incorporate an expensive array-based replication. What it really does is provide a mechanism to replicate a virtual machine using the existing Ethernet infrastructure and recover them when there is a need. It directly integrates with the vSphere platform and is available with Standard, Enterprise, and Enterprise Plus editions. It is storage agnostic, which means that a virtual machine or its disk files can be replicated to a data store, regardless of it being a VMFS volume or an NFS mount. You can learn more about vSphere Replication from the book Disaster Recovery using VMware vSphere Replication and vCenter Site Recovery Manager, Abhilash GB, ISBN 9781782176442, Packt Publishing.