vSphere 5 - 17

This video will show you how to install ESXi 5.0 on a drive with an existing ESX 4.1 installation and VMFS datastore present. ESXi 5.0 uses the same installer for fresh installations and upgrades. If the installer finds an existing ESX 4.x or ESXi 4.x installation, it allows you to performs an upgrade.

During this upgrade, the ESXi installer will offer several options for preserving or discarding existing ESX host settings and VMFS datastores. If an earlier version of ESX and VMFS was found by the installer, it will show you the selected storage device contains an installation of ESX and a VMFS datastore. You can choose whether to upgrade or install and overwrite the existing installation. You can also choose whether to preserve or overwrite the existing VMFS datastore. After upgrading from ESX  4.1 to ESXi 5.0, only the relevant settings will be migrated.

UEFI virtual BIOS. Virtual machines running on ESXi 5.0 can boot from and use the Unified Extended Firmware Interface (UEFI). When you create a new virtual machine on an ESXi 5.0 host you have the option to choose for virtual machine version 8. This new version brings a lot of extra (scalability) features but there’s one other interesting new feature. The Extensible Firmware Interface can be selected to replace the BIOS of a virtual machine. EFI is the successor of the traditional BIOS which is used since the introduction of the IBM PC back in 1981. If you want to host Apple Mac OS X 10.6 in a virtual machine, you need EFI. In this video I’ll show you how to get access to the EFI interface. I’ll also show you how you can get access to the pre-OS command line environment.

When you select a guest operating system, BIOS or Extensible Firmware Interface (EFI) is selected by default, depending on which firmware the operating system uses. Mac OS X Server guest operating systems support only EFI. If the operating system supports both BIOS and EFI, you can change the default before you install the guest operating system. Use the Virtual Machine Properties dialog box at the end of the creation process or after the virtual machine is created. The Firmware selection pane is on the Options tab under Advanced > Boot Options.

vSphere 5.0 also supports booting ESXi hosts from the Unified Extensible Firmware Interface (UEFI). With UEFI you can boot systems from hard drives, CD-ROM drives, or USB media. Booting over the network requires the legacy BIOS firmware and is not available with UEFI.

So what does Profile-Driven Storage try to achieve? Very simply - minimize the amount of time required to provision virtual machines. Provisioning virtual machines isn’t only just selecting a random datastore. You will need to know what the requirements are of the virtual machine and then select the appropriate volume to the best of your knowledge. Profile-Driven Storage tries to help with that by providing better insight into storage characteristics and allowing for custom-tags and linking virtual machines to profiles. vSphere Storage APIs for Storage Awareness is a new set of APIs which will enable vCenter to see the capabilities of the storage array LUNs/datastores, making it much easier to select the appropriate disk for virtual machine placement. Storage capabilities, such as RAID level, Thin or Thick Provisioned, Replication State and much more can now be made visible within vCenter. vSphere Storage APIs for Storage Awareness eliminates the need for maintaining massive spreadsheets detailing the storage capabilities of each LUN needed to guarantee the correct SLA to virtual machines. It helps SDRS make a decision about where to Storage vMotion a VM too, because if two datastore are backed by the same set of spindles, then it doesn’t make sense to move the VM to the other datastore.

With Storage Awareness APIs, storage vendors can provide vSphere with information about the storage environment. It enables tighter integration between storage and the virtual infrastructure. Information about storage health status, configuration info, capacity and thin provisioning info etc For the first time we have an end to end story, i.e. storage array informs VASA storage provider of capabilities & then the storage provider informs vCenter, so now users can see storage array capabilities from vSphere client. Through the new VM Storage Profile-Driven Storageles, these storage capabilities can then be displayed in vCenter to assist administrators in choosing the right storage in terms of space, performance and SLA requirements. This information enables the administrator to take the appropriate actions based on health & usage information.

Currently we identify the requirements of the virtual machine, try to find the optimal datastore based on the requirements and create the virtual machine or disk. In some cases customers even periodically check if VMs are compliant but in many cases this is neglected. Storage DRS only solves that problem partly. We will need to manually identify the correct datastore cluster, and even when grouping datastores into a datastore cluster, we need to manually verify if all LUNs are “alike”. When using Profile-Driven Storage and Storage DRS together, these problems are solved. A datastore cluster can be created based on the characteristics provided through VASA or the custom tags. When deploying virtual machines, a storage profile can be selected ensuring that the virtual will be on compliant storage.

VMware HA clusters enable a collection of ESXi hosts to work together so that, as a group, they provide higher levels of availability for virtual machines than each ESXi host could provide individually. When you plan the creation and usage of a new VMware HA cluster, the options you select affect the way that cluster responds to failures of hosts or virtual machines.

Before creating a VMware HA cluster, you should be aware of how VMware HA identifies host failures and isolation and responds to these situations. You also should know how admission control works so that you can choose the policy that best fits your failover needs. After a cluster has been established, you can customize its behavior with advanced attributes and optimize its performance by following recommended best practices.

VMware HA provides high availability for virtual machines by pooling them and the hosts they reside on into a cluster. Hosts in the cluster are monitored and in the event of a failure, the virtual machines on a failed host are restarted on alternate hosts.

When you create a VMware HA cluster, a single host is chosen as the master host to communicate with vCenter Server and to monitor the state of the other, slave, hosts and their virtual machines. Different types of host failures are possible and must be detected and appropriately dealt with. To do this, the master host must distinguish between a failed host and one that is in a network partition. Datastore heartbeating is used to do this.

Auto Deploy is a new method for provisioning ESXi hosts in vSphere 5.0.  At a high level the ESXi host boots over the network (using PXE/gPXE), contacts the Auto Deploy Server which loads ESXi into the hosts memory.  After loading the ESXi image the Auto Deploy Server coordinates with vCenter Server to configure the host (using Host Profiles and Answer Files (answer files are new in 5.0).  Auto Deploy eliminates the need for a dedicated boot device, enables rapid deployment for many hosts, and also simplifies ESXi host management by eliminating the need to maintain a separate “boot image” for each host.

Image profiles and VIBs are available in software depots from VMware or from VMware partners, and managed using the Image Builder PowerCLI. You can use software depots, image profiles, and software packages (VIBs) to specify the software you want to use during installation or upgrade of an ESXi host. Understanding how depots, profiles, and VIBs are structured and where you can use them is a prerequisite for in-memory installation of a custom ESXi ISO, for provisioning ESXi hosts using VMware Auto Deploy, and for some custom upgrade operations.

VIB A VIB is an ESXi software package. VMware and its partners package solutions, drivers, CIM providers, and applications that extend the ESXi platform as VIBs.
VIBs can be used to create and customize ISO images or installed asynchronously onto ESXi hosts. VIBs are available from software depots.

Image Profile An image profile defines an ESXi image and consists of VIBs (software packages). An image profile always includes a base VIB, and might include
additional VIBs. You examine and define an image profile using the Image Builder PowerCLI.

In vSphere 5.0, VMware has released a new storage appliance called VSA. VSA is an acronym for “vSphere Storage Appliance”. This appliance is aimed at our SMB (Small-Medium Business) customers who may not be in a position to purchase a SAN or NAS array for their virtual infrastructure, and therefore do not have shared storage. Without access to a SAN or NAS array, SMB customers are unable to implement many of vSphere’s core technologies, such as vSphere HA & vMotion. Customers who decide to deploy a VSA can now benefit from many additional vSphere features without having to purchase a SAN or NAS device to provide them with shared storage.

Each ESXi server has a VSA deployed to it as a Virtual Machine.The appliances use the available space on the local disk(s) of the ESXi servers & present one replicated NFS volume per ESXi server. This replication of storage makes the VSA very resilient to failures. The NFS datastores exported from the VSA can now be used as shared storage on all of the ESXi servers in the same datacenter. The VSA creates shared storage out of local storage for use by a specific set of hosts. This means that vSphere HA & vMotion can now be made available on low-end (SMB) configurations, without external SAN or NAS servers.

There is a CAPEX saving achieved by SMB customers as there is no longer a need to purchase a dedicated SAN or NAS devices to achieve shared storage.There is also an OPEX saving as the management of the VSA may be done by the vSphere Administrator and there is no need for dedicated SAN skills to manage the appliances. The installation & configuration is also much simpler than that of a physical storage array or other storage appliances.

Link to the VSA Installation Demo

This feature delivers the DRS benefits of resource aggregation, automated initial placement, and bottleneck avoidance to storage. You can group and manage similar datastores as a single load-balanced storage resource called a datastore cluster. Storage DRS makes VMDK placement and migration recommendations to avoid I/O and space utilization bottlenecks on the datastores in the cluster. Storage DRS takes care of the initial placement of virtual machines and VMDK files. This placement is based on Space and I/O capacity. Storage DRS will select the best datastore to place this virtual machine or virtual disk in the selected Datastore Cluster. When Storage DRS is set to fully automatic, it will do automated load balancing actions. Of course this can be configured as manual as well and that is actually the default today. Load balancing again is based on space and I/O capacity. If and when required Storage DRS will make recommendations based space and I/O capacity. It will however only do this when a specific threshold is reached.

A datastore cluster is a collection of datastores aggregated into a single unit of consumption for an administrators. When a datastore cluster is created, Storage DRS can manage the storage resources comparable to how DRS manages compute resources in a cluster. As with a cluster of hosts, a datastore clusters is used to aggregate storage resources, enabling smart and rapid placement of new virtual machines and virtual disk drives and load balancing of existing workloads. When you create a VM you will be able to select a Datastore Cluster as opposed to individual datastores. Storage DRS provides initial placement recommendations to datastores in a Storage DRS-enabled datastore cluster based on I/O and space capacity.

During the provisioning of a virtual machine, a datastore cluster can be selected as the target destination for this virtual machine or virtual machine disk after which a recommendation for initial placement is done based on I/O and space capacity. Initial Placement in a manual provisioning process has proven to be very complex in most environments and as such important provisioning factors like current I/O load or space utilization are often ignored. Storage DRS ensures initial placement recommendations are made in accordance with space constraints and with respect to the goals of space and I/O load balancing. Although people are really excited about automated load balancing, it is Initial Placement where most people will start off with and where most people will benefit from the most as it will reduce operational overhead associated with the provisioning of virtual machines.

Ongoing balancing recommendations are made when one or more datastores in a datastore cluster exceeds the user-configurable space utilization or I/O latency thresholds. These thresholds are typically defined during the configuration of the datastore cluster. Storage DRS utilizes vCenter Server’s datastore utilization reporting mechanism to make recommendations whenever the configured utilized space threshold is exceeded. I/O load is evaluated by default every 8 hours currently with a default latency threshold of 15ms. Only when this I/O latency threshold is exceeded Storage DRS will calculate all possible moves to balance the load accordingly while considering the cost and the benefit of the migration. If the benefit doesn’t last for at least 24 hours, Storage DRS will not make the recommendation.

I’ve recorded a short interview with Duncan Epping and Frank Denneman. They have released their new book “VMware vSphere 5.0 Clustering Technical Deepdive”. This book is available at Amazon in full colour and e-reader format. Frank and Duncan have written “vSphere 5.0 Clustering Technical Deepdive” to give you a better understanding of all the new clustering features vSphere 5.0 offers and how these integrate with each other.



VMware vSphere 5.0 Clustering Technical Deepdive zooms in on three key components of every VMware based infrastructure and is by no means a "how to" guide. It covers the basic steps needed to create a vSphere HA and vSphere DRS cluster and to implement vSphere Storage DRS. Even more important, it explains the concepts and mechanisms behind HA, DRS and Storage DRS which will enable you to make well educated decisions. This book will take you in to the trenches of HA, DRS and Storage DRS and will give you the tools to understand and implement e.g. HA admission control policies, DRS resource pools, Datastore Clusters and resource allocation settings. On top of that each section contains basic design principles that can be used for designing, implementing or improving VMware infrastructures and fundamental supporting features like (Storage) vMotion, Storage I/O Control and much more are described in detail for the very first time.

This book is also the ultimate guide to be prepared for any HA, DRS or Storage DRS related question or case study that might be presented during VMware VCDX, VCP and or VCAP exams.

Coverage includes

HA node types
HA isolation detection and response
HA admission control
VM Monitoring
HA and DRS integration
DRS imbalance algorithm
Resource Pools
Impact of reservations and limits
CPU Resource Scheduling
Memory Scheduler
DPM
Datastore Clusters
Storage DRS algorithm
Influencing SDRS recommendations

Be prepared to dive deep!

For the EMEA folks comcol.nl offered to distribute it again, paper black & white can be found here, and full color here. For more information about the paperback, please visit this link.