Archive for VCAP5 DCA

Configure a shared repository

images

Configure Update Manager to Use the Internet as a Download Source

If your deployment system is connected to the Internet, you can directly download ESX/ESXi patches and extensions, as well as virtual appliance upgrades.

Procedure

  • Connect the vSphere Client to a vCenter Server system with which Update Manager is registered, and on the Home page, click Update Manager under Solutions and Applications.
  • If your vCenter Server system is part of a connected group in vCenter Linked Mode, you must specify the Update Manager instance to use, by selecting the name of the corresponding vCenter Server system in the navigation bar.
  • On the Configuration tab, under Settings, click Download Settings.
  • In the Download Sources pane, select Direct connection to Internet.
  • Choose the type of updates to download by selecting or deselecting the check box next to the type of update.
  • You can choose whether to download virtual appliance upgrades and host patches and extensions. You cannot edit the download source location of the default ESX/ESXi patches and extensions. You can only enable or disable downloading.
  • (Optional) Add an additional third-party download source for virtual appliances or hosts that are running ESX/ESXi 4.0 and later.
  • Click Apply.
  • Click Download Now to run the VMware vSphere Update Manager Update Download task
  • All notifications and updates are downloaded immediately even if the Enable scheduled download checkbox is not selected in Configuration > Notification Check Schedule or Configuration > Download Schedule, respectively

updatemanager

Add a new Download Source

If you use the Internet as a download source for updates, you can add a third-party URL address to download virtual appliance upgrades, as well as patches and extensions for hosts that are running ESX/ESXi 4.0 and later.

Prerequisites

Connect the vSphere Client to a vCenter Server system with which Update Manager is registered, and on the Home page, click Update Manager under Solutions and Applications. If your vCenter Server system is part of a connected group in vCenter Linked Mode, you must specify the Update Manager instance to use, by selecting the name of the corresponding vCenter Server system in the navigation bar.

Procedure

  • On the Configuration tab, under Settings, click Download Settings.
  • In the Download Sources pane, select Direct connection to Internet.
  • Click Add Download Source.
  • In the Add Download Source window, type the new download source URL.

updatemanager2

Update Manager supports both HTTP and HTTPS URL addresses. You should specify HTTPS URL
addresses, so that the data is downloaded securely. The URL addresses that you add must be complete and contain the index.xml file, which lists the vendor and the vendor index.
Note: The proxy settings for Update Manager are applicable to third-party URL addresses too. You can configure the proxy settings from the Proxy Settings pane.

  • (Optional) Type a URL description.
  • Click Validate URL to verify that the URL is accessible.
  • Click OK.
  • Click Apply.
  • Click Download Now to run the VMware vSphere Update Manager Update Download task.
  • All notifications and updates are downloaded immediately even if the Enable scheduled download checkbox is not selected in Configuration > Notification Check Schedule or Configuration > Download Schedule, respectively.
  • The location is added to the list of Internet download sources.

Use a Shared Repository as a Download Source 

You can configure Update Manager to use a shared repository as a source for downloading virtual appliance upgrades, as well as ESX/ESXi patches, extensions, and notifications.

A shared repository is a location within your firewall where UMDS downloads patches or VA upgrades from various vendors. When the patches or VA upgrades are required for remediation, the system retrieves them from the Shared Repository rather than from the internet. It lets you create secure environments and save time

Network Shares are not supported as Update Manager does not have access to Network shares. HTTP URLs and Local Disks only

Prerequisites

You must create the shared repository using UMDS and host it on a Web server or a local disk. The UMDS version you use must be of a version compatible with your Update Manager installation.

Once you have configured UMDS and downloaded updates to a certain folder on another server, you can run the following to export the updates from this server to the Update Manager server on vCenter Server by running the following command

  • vmware-umds -E –export-store \\vCenterserver\SharedFolder

where shared folder is a local disk folder on the vCenter Server

Procedure

  • On the Configuration tab, under Settings, click Download Settings.
  • In the Download Sources pane, select Use a shared repository.
  • Enter the path or the URL to the shared repository.
  • For example, C:\repository_path\, https://repository_path/, or http://repository_path/

In these examples, repository_path is the path to the folder to which you have exported the downloaded upgrades, patches, extensions, and notifications. In an environment where the Update Manager server does not have direct access to the Internet, but is connected to a machine that has Internet access, the folder can be on a Web server.

  • You can specify an HTTP or HTTPS address, or a location on the disk on which Update Manager is installed. HTTPS addresses are supported without any authentication.

IMPORTANT You cannot use folders located on a network drive as a shared repository. Update Manager does not download updates from folders on a network share either in the Microsoft Windows Uniform Naming Convention form (such as \\Computer_Name_or_Computer_IP\Shared), or on a mapped network drive (for example, Z:\).

  • Click Validate URL to validate the path.

IMPORTANT If the updates in the folder you specify are downloaded with a UMDS version that is not compatible with the Update Manager version you use, the validation fails and you receive an error message. You must make sure that the validation is successful. If the validation fails, Update Manager reports a reason for the failure. You can use the path to the shared repository only when the validation is successful.

  • Click Apply.
  • Click Download Now to run the VMware vSphere Update Manager Update Download task and to download the updates immediately.
  • The shared repository is used as a source for downloading upgrades, patches, and notifications.

um2

Install and Configure Update Manager Download Service

What is UMDS?

VMware vSphere Update Manager Download Service (UMDS) is an optional module of Update Manager. UMDS downloads upgrades for virtual appliances, patch metadata, patch binaries, and notifications that would not otherwise be available to the Update Manager server.

For security reasons and deployment restrictions, vSphere, including Update Manager, might be installed in a secured network that is disconnected from other local networks and the Internet. Update Manager requires access to patch information to function properly. In such an environment, you can install UMDS on a computer that has Internet access to download upgrades, patch binaries, and patch metadata, and then export the downloads to a portable media drive so that they become accessible to the Update Manager server.

In a deployment where the machine on which Update Manager is installed has no Internet access, but is connected to a server that has Internet access, you can automate the export process and transfer files from UMDS to the Update Manager server by using a Web server on the machine on which UMDS is installed.

UMDS 5.1 supports patch recalls and notifications. A patch is recalled if the released patch has problems or potential issues. After you download patch data and notifications with UMDS, and export the downloads so that they become available to the Update Manager server, Update Manager deletes the recalled patches and displays the notifications on the Update Manager Notifications tab.

Installing UMDS

Pre-Requisites

  • It will not install on a Windows 2008 R2 Server running as a DC
  • You cannot upgrade UMDS 4.x to UMDS 5.1, but under certain conditions you can perform a fresh installation of UMDS 5.1 and use an existing patch store from UMDS 4.x. You can install UMDS only on 64-bit machines.
  • Before installing UMDS, you must create a database instance and configure it to ensure that all tables are placed in it. You must configure a 32-bit DSN and test the DSN from ODBC. If you are using Microsoft SQL Server 2008 R2 Express, you can install and configure the database when you install UMDS
  • You should not install UMDS 5.1 with an existing UMDS 4.x download directory if your environment contains both Update Manager 4.x and Update Manager 5.x instances. In such a case, you need a UMDS 4.x and a UMDS 5.x installation on two separate machines, in order to export updates for the respective Update Manager versions.
  • UMDS and Update Manager must be installed on different machines
  • Ensure that the machine on which you install UMDS has Internet access

Procedure

  • Insert the VMware vSphere Update Manager installation DVD into the DVD drive of the Windows server that will host UMDS.
  • Browse to the umds folder on the DVD and run VMware-UMDS.exe. (One of the first folders you will see!)
  • Select the language for the installation and click OK
  • (Optional) If the wizard prompts you, install the required items such as Windows Installer 4.5. This step is required only if Windows Installer 4.5 is not present on your machine and you must perform it the first time you install a vSphere 5.x product. After the system restarts, the installer launches again.
  • Review the Welcome page and click Next.
  • Read the patent agreement and click Next.
  • Accept the terms in the license agreement and click Next.
  • Select the database options and click Next.
  • If you do not have an existing database, select Install a Microsoft SQL Server 2008 R2 Express instance (for small scale deployments).
  • If you want to use an existing database, select Use an existing supported database and select your database from the list of DSNs. If the DSN does not use Windows NT authentication, enter the user name and password for the DSN and click Next.
  • Enter the Update Manager Download Service proxy settings and click Next.
  • Select the Update Manager Download Service installation and patch download directories and click Next.
  • If you do not want to use the default locations, you can click Change to browse to a different directory. You can select the patch store to be an existing download directory from a previous UMDS 4.x installation and reuse the applicable downloaded updates in UMDS 5.1. After you associate an existing download directory with UMDS 5.1, you cannot use it with earlier UMDS versions.
  • (Optional) In the warning message about the disk free space, click OK.
  • Click Install to begin the installation.
  • Click OK in the Warning message notifying you that .NET Framework 3.5 SP1 is not installed.
  • The UMDS installer installs the prerequisite before the actual product installation.
  • Click Finish.
  • Reboot

Setting Up and Using UMDS

You can set up UMDS to download upgrades for virtual appliances, or patches and notifications for ESX/ESXi hosts. You can also set up UMDS to download ESX/ESXi 4.x and ESXi 5.x patch binaries, patch metadata, and notifications from third-party portals.

After you download the upgrades, patch binaries, patch metadata, and notifications, you can export the data to a Web server or a portable media drive and set up Update Manager to use a folder on the Web server or the media drive (mounted as a local disk) as a shared repository.

You can also set up UMDS to download ESX/ESXi 4.x and ESXi 5.x patches and notifications from third-party portals.

To use UMDS, the machine on which you install it must have Internet access. After you download the data you want, you can copy it to a local Web server or a portable storage device, such as a CD or USB flash drive.

The best practice is to create a script to download the patches manually and set it up as a Windows Scheduled Task that downloads the upgrades and patches automatically.

Set Up the Data to Download with UMDS

By default UMDS downloads patch binaries, patch metadata, and notifications for hosts. You can specify which patch binaries and patch metadata to download with UMDS.

  • Log in to the machine where UMDS is installed, and open a Command Prompt window.
  • Navigate to the directory where UMDS is installed.
  • The default location in 64-bit Windows is C:\Program Files (x86)\VMware\Infrastructure\Update Manager.
  • Check the setup by typing vmware-umds -G

umdsg

  • Specify the type of updates to download by using the commands below
  • vmware-umds.exe -s –enable-host –disable-va

UMDSEnable

  • Specify the updates to download by using the commands below to delete the versions you don’t want leaving version 5.1.0
  • vmware-umds.exe -s -d embeddedEsx-5.0.0
  • vmware-umds.exe -s -d embeddedEsx-4.1.0
  • vmware-umds.exe -s -d embeddedEsx-4.0.0
  • Next run vmware-umds.exe -D

umds1

  • Next we need to export the Downloaded Updates to a removable device which has been given the drive letter F:\
  • Type vmware-umds.exe -E –export-store F:\
  • Verify that all files are exported to the portable media drive, and then safely remove it and connect it to the machine on which the Update Manager server is installed.
  • Modify the Shared Repository Path in Update Manager to F:\
  • Note: The path can only contain one directory level, otherwise it will fail.  For example the path should be d:\repository, but it cannot be d:\repository\patches.  When it is finally exported you can then move the repository to a physical media or any portable storage device.

UMDS Commands

umds

Identify Firewall Access Rules for Update Manager

images

Firewall Access Rules

If you access ESXi hosts through vCenter Server, you typically protect vCenter Server using a firewall. This firewall provides basic protection for your network.
A firewall might lie between the clients and vCenter Server. Alternatively, vCenter Server and the clients can be behind the firewall, depending on your deployment. The main point is to ensure that a firewall is present at what you consider to be an entry point for the system.

Update1

ESXi Security Guide

Please see Pages 23-25 for extra Port Information

ESXi Security Guide

Use Host Profiles to manage Answer Files

h2p

What is an Answer File?

For hosts provisioned with Auto Deploy, the answer file contains the user input policies for a host profile. The file is created when the profile is initially applied to a particular host.
To apply a host profile to a host, the host must be placed into maintenance mode. During this process, the user is prompted to type answers for policies that are specified during host profile creation.
Placing the host into maintenance mode each time you apply a profile to the host can be costly and time consuming. A host provisioned with Auto Deploy can be rebooted while the host profile is attached to the host. After rebooting values stored in the answer file help the host provisioned with Auto Deploy to apply the profile. An answer file is created that contains a series of key value pairs for the user input options.

Check Answer File Status

The answer file status indicates the state of the answer file. The status of an answer file can be

  • Complete
  • Incomplete
  • Missing
  • Unknown

Prerequisites
The answer file status can only be checked when the host profile is attached to a host.

Procedure

  • In the host profiles view, click Check Answer File.

AnswerFileStatus

The Answer File Status for the host profile is updated. The status indicates one of the following states:

  • Incomplete The answer file is missing some of the required user input answers.
  • Complete The answer file has all of the user input answers needed.
  • Unknown The host and associated profile exist but the status

AnswerFile

Update Answer File

  • Right click on a host or cluster and select Update Answer File

UpdateAnswerFile2

  • Adjust the Answer File

Use Host Profiles to deploy vDS and vStorage Policies

h2p

vDS Setup using Host Profiles

Host Profiles is the recommended method for deploying a vDS over a large population of similarly configured hosts.

vds

Considerations for using Host Profiles for Deploying vDS

  • Target hosts must be in Maintenance Mode. This means all VMs must be powered off or migrated to other hosts.
  • An ESX Host Profile can be applied to ESX and ESXi hosts. An ESXi Host Profile can only be applied to an ESXi Host. If you have a mix of ESX and ESXi hosts, then create the Host Profile from an ESX host. The Host Profile feature in vCenter Server is able to translate and apply the ESX Service Console definition to an ESXi VMkernel port for management access.

Process Overview

  • Create vDS (without any associated hosts)
  • Create Distributed Virtual Port Groups on vDS to match existing or required environment
  • Add host to vDS and migrate vmnics to dvUplinks and Virtual Ports to DV Port Groups
  • Delete Standard Switch from host
  • Create Host Profile of Reference Host
  • Place candidate host to have the profile applied in Maintenance Mode
  • Attach and apply host profile to candidate hosts
  • Migrate VM networking for VMs and take hosts out of Maintenance Mode.

Detailed Overview

For a more detailed description of the above steps read pages 24 to 28 of the document below from VMware

VMware vNetwork Distributed Switch: Migration and Configuration

http://www.vmware.com/files/pdf/techpaper/VMW-Host-Profiles-Tech-Overview.pdf

Summary of Migration Methods

The table below summarizes the deployment situations and suggested methods for deployment of the vNetwork Distributed Switch:

vds2

Use Host Profiles to deploy vStorage Policies

You can configure storage options, including

  • Native Multi-Pathing (NMP)
  • Pluggable Storage Architecture (PSA)
  • FCoE adapters
  • iSCSI adapters
  • NFS storage

Capture

Caveats

  • Use the vSphere CLI to configure or modify the NMP and PSA policies on a reference host first, and then extract the host profile from that host. If you use the Profile Editor to edit the policies, to avoid compliance failures, make sure that you thoroughly understand interrelationships between the NMP and PSA policies and the consequences of changing individual policies. For information on the NMP and PSA, see the vSphere Storage documentation.
  • Setting values for the Initiator IPv6 Address and Initiator IPv6 Prefix options in a host profile with independent hardware iSCSI adapters has no effect on the HBA because no independent iSCSi HBAs have IPv6 support.

Implement and Maintain Host Profiles

h2p

What are Host Profiles?

The host profiles feature creates a profile that encapsulates the host configuration and helps to manage the host configuration, especially in environments where an administrator manages more than one host or cluster in vCenter Server.
Host profiles eliminates per-host, manual, or UI-based host configuration and maintains configuration consistency and correctness across the datacenter by using host profile policies. These policies capture the blueprint of a known, validated reference host configuration and use this to configure networking, storage, security, and other settings on multiple hosts or clusters. You can then check a host or cluster against a profile’s configuration for any deviations.

Workflow
You perform host profiles tasks in a certain workflow order. You must have an existing vSphere installation with at least one properly configured host.

  • Set up and configure the host that will be used as the reference host. A reference host is the host from which the profile is created.
  • Create a profile using the designated reference host.
  • Attach a host or cluster to the profile.
  • Check the host’s compliance to the reference host’s profile. If all hosts are compliant with the reference host, they are correctly configured.
  • Apply the host profile of the reference host to other hosts or clusters of hosts.

Instructions for creating Host Profiles

  • Go to the Home Page in vClient and click on Host Profiles
  • Click Create a New Profile

Profile1

  • Create a new Profile or import a Profile

Profile2

  • Put a name and description in

Profile3

  • Click Next and Review the Summary > Finish

Profile4

  •  Once it has created the profile click Edit to edit the profile

Profile5

Attach a profile to one or more Hosts/Cluster

  • Click Attach Host/Cluster
  • Select Hosts or Cluster

attachhost

Check Compliance

When you have first added a host or cluster to your profile, it will look like this

ComplianceHost

  • Highlight a host or your cluster and click Check Compliance
  • I have made a deliberate error so it shows Non Compliant as per below

ComplianceFailure1

  • The Compliance Failure shows as per below screenprint

ComplianceFailure

  • After rectifying the DNS errors and turning off SSH in the Security Profile on my reference host, I now need to right click on my Host Profile and select Update Profile
  • Then Enter Maintenance Mode on my Non-Compliant Host
  • And re-apply the host profile
  • Check Compliance (Hurrah!)

Compliant2

  • Exit Maintenance Mode
  • it should now look like the below

Compliant4

Create Sub-Profiles

On the left side of the Profile Editor, you can expand the host profile. Each host profile is composed of several Sub-Profiles that are designated by functional group to represent configuration instances. Sub-Profiles are for e.g.

  • Storage configuration
  • Networking configuration
  • Date and time configuration
  • Firewall configuration
  • Security Configuration

Each Sub-Profile contains many policies and compliance checks that describe the configuration that is relevant to the profile. Each policy consists of one or more options that contains one or more parameters

  • Open the Profile Editor for the profile you wish to edit (as outlined above)
  • On the left side of the Profile Editor, expand a sub-profile until you reach the policy you want to edit (noted with a “folder” icon)
  • Right click the policy and select “Add Profile

HP

  • A new profile will be created under the given target
  • Highlight the new profile and expand the policy until you see Configuration details

HP3

  • Configure the policy options you want
  • Click OK and Save

Great Youtube Video

http://www.youtube.com/watch?v=tDDK97MR-HU&feature=channel_page

Test FT failover, secondary restart and app fault tolerance in a FT VM

Fault Tolerance failure scenarios

Fault Tolerance failures are only triggered when there is no communication between the primary and secondary VMs.

vmware_fault_tolerance

Three scenarios may occur

Deterministic

This is where you can predict how a failover will occur

  • An ESXi host fails which causes complete host failover
  • The Primary VM process fails or becomes unresponsive on the ESXi host
  • A Fault Tolerance test is initiated from vCenter Server

Reactionary

This is where a failover may occur but you don’t know the expected outcome ahead of time. These events are not predicable as there is a race between the Primary and Secondary VMs to see which one should be the live one. The race prevents a split brain scenario that can cause data corruption

  • The Fault Tolerant NIC is interrupted or fails
  • The Fault Tolerant NIC communication is very slow

No action taken

This is where no failure can occur because Fault Tolerance does not monitor for this type of event

  • Management network interruption or failure
  • VM network interruption or failure
  • HBA Failures that do not affect the entire host
  • Any combination of the above

Testing Fault Tolerance

VMware provides a Test Failover function from the VM which is the best option for testing

3 Tests

  • Select the Test Failover Function from the Fault Tolerance menu on the Primary VM

This tests the Fault Tolerance functionality in a fully supported and non invasive way. In this scenario, the Virtual Machine fails over from Host A to Host B and a secondary VM is started back up again. VMware HA failure does not occur in this case

  • Host Failure

This can be accomplished by pulling the power cord of the host, rebooting the host or powering off the host from a remote KVM such as ILO, DRAC, IMM and RSA etc. The secondary VM on Host B takes over immediately and continues to process information for the VM. VMware HA occurs

  • Virtual Machine process on Host A fails

The scenario can be accomplished by terminating the active process for the VM by logging into Host A. The secondary VM takes over and no VMware HA failure occurs. VMware do not recommend testing in this way

Analyse virtual machine workload to determine optimum slot size

images

Recommendations

  • If you have one VM which is configured with a very high amount of memory, you can either lower its configured memory, or take it out of the cluster and run it on any other standalone ESX host. This will increase the number of slots available with the current hardware
  • Remove any CPU reservations on any VM(s) that are greater than the max speed of the processors in the hosts.
  • If you have just one VM with a really high reservation you can set the following advanced settings to lower the slot size being used during these calculations: das.slotCpuInMHz or das.slotMemInMB. To avoid not being able to power on the VM with high reservations these VM will take up multiple slots. Keep in mind that when you are low on resources this could mean that you are not able to power-on this high reservation VM as resources are fragmented throughout the cluster instead of located on a single host.
  • Create Resource Pools with Reservations to get around fragmented slot sizes which can occur when using Host Failure Tolerates Admission Policy
  • Use das.vmMemoryMinMB <value> This options/value pair overrides the default memory slot size value used for admission control for VMware HA where <value> is the amount of RAM in MB to be used for the calculation if there are no larger memory reservations. By default this value is set to 256MB. This is the minimum amount of memory in MB sufficient for any VM in the cluster to be usable
  • Use das.vmCPUMinMHz <value> This options/value pair overrides the default CPU slot size value used for admission control for VMware HA where <value> is the amount of CPU in MHz to be used for the calculation if there are no larger memory reservations. By default this value is set to 256MHz
  • Set the “Allow Virtual Machines to be powered on even if they violate availability constraints” in the configuration of the cluster. In this case it ignores the above calculation and will try to power on as many VM’s as possible in case of HA failover

Slot Size Example

Here we can see someone has set a reservation of 8GB RAM somewhere

image1

Once the reservation of 8GB is taken off, you can see the Slot size instantly adjust back to a more sensible size

image2

Fault Tolerance

What is Fault Tolerance?

FT is the evolution of continuous availability that utilises VMware vLockstep technology to keep a primary and secondary virtual machine in sync. It is based on the record/playback technology used in VMware Workstation. It streams non-deterministic events and then replay will occur deterministically. This means it matches instruction for instruction and memory for memory to create identical processing

Deterministic means that the processor will execute the same instruction set on the secondary VM

Non-Deterministic means event functions such as network/disk/mouse and keyboard including hardware interrupts which are also played back

FT1

The Primary and Secondary VMs continuously exchange heartbeats. This exchange allows the virtual machine pair to monitor the status of one another to ensure that Fault Tolerance is continually maintained. A transparent failover occurs if the host running the Primary VM fails, in which case the Secondary VM is immediately activated to replace the Primary VM. A new Secondary VM is started and Fault Tolerance redundancy is reestablished within a few seconds. If the host running the Secondary VM fails, it is also immediately replaced. In either case, users experience no interruption in service and no loss of data

Fault Tolerance avoids “split-brain” situations, which can lead to two active copies of a virtual machine after recovery from a failure. Atomic file locking on shared storage is used to coordinate failover so that only one side continues running as the Primary VM and a new Secondary VM is respawned automatically.

Use Cases

  • Applications that need to be available at all times, especially those that have long-lasting client connections that users want to maintain during hardware failure.
  • Custom applications that have no other way of doing clustering.
  • Cases where high availability might be provided through custom clustering solutions, which are too complicated to configure and maintain.
  • On demand protection for VMs running end of month reports or financials

Best Practices for Fault Tolerance

To ensure optimal Fault Tolerance results, VMware recommends that you follow certain best practices. In addition to the following information, see the white paper VMware Fault Tolerance Recommendations and Considerations at http://www.vmware.com/resources/techresources/10040

Requirements for FT

  • Cluster Requirements
  • Host Requirements
  • VM Requirements

Cluster Requirements

  • Host certificate checking must be enabled. Default for vSphere 4.1 but you may need to enable this (vCenter Server Settings > SSL Settings > Select the vCenter requires verified host SSL certificates)
  • The cluster must have at least 2 ESXi hosts running the same FT Version or build number
  • HA must be enabled on the cluster
  • EVC must be enabled if you want to use FT in conjunction with DRS or DRS will be disabled

Hosts Requirements

  • The ESXi hosts must have access to the same datastores and networks
  • The ESXi hosts must have a FT Logging network setup
  • The FT Logging network must have at least 1GB connectivity
  • NICs can be shared if necessary
  • The ESXi hosts CPUs must be FT compatible
  • Host must be licensed for FT
  • Hardware Virtualisation must be enabled on the BIOS of the hosts to enable CPU support for FT
  • It is recommended that Power Management is turned off in the BIOS. This helps ensure uniformity in the CPU speeds

VMs Requirements

  • Only VMs with a single CPU are supported
  • VMs must be running a supported O/S
  • VMs must be stored on shared storage available to all hosts
  • FC, iSCSI, FCOE and NFS are supported
  • A VMs disk must be eager zeroedthick format or a Virtual RDM (Physical RDMs are not supported)
  • No VM snapshots
  • The VM must not be a linked clone
  • No USB, Sound devices, serial ports or parallel ports configured
  • The VM cannot use NPIV
  • Nested Page Tables/Extended Page Tables are not supported
  • The VM cannot use NIC Passthrough
  • The VM cannot use the older vlance drivers
  • No CD-ROM or floppy devices attached
  • The VM cannot use a paravirtualised kernel
  • VMs must be on the correct Monitor Mode

monitormode

Caveats

  • You can use vMotion but not Storage vMotion and therefore Storage sDRS
  • Hot Plugging is not allowed
  • You cannot change the network settings while the VM is on
  • Because snapshots are not supported, you will not be able to use any backup mechanism that uses snapshots. You can disable FT first before backing up

Configure FT Networking for Host Machines

On each host that you want to add to a vSphere HA cluster, you must configure two different networking switches so that the host can also support vSphere Fault Tolerance.
To enable Fault Tolerance for a host, you must complete this procedure twice, once for each port group option to ensure that sufficient bandwidth is available for Fault Tolerance logging. Select one option, finish this procedure, and repeat the procedure a second time, selecting the other port group option.

Prerequisites

  • Multiple gigabit Network Interface Cards (NICs) are required. For each host supporting Fault Tolerance, you need a minimum of two physical gigabit NICs. For example, you need one dedicated to Fault Tolerance logging and one dedicated to vMotion.
  • VMware recommends three or more NICs to ensure availability.
  • The vMotion and FT logging NICs must be on different subnets
  • IPv6 is not supported on the FT logging NIC.

Procedure

  • Connect vSphere Client to vCenter Server.
  • In the vCenter Server inventory, select the host and click the Configuration tab.
  • Select Networking under Hardware, and click the Add Networking link
  • The Add Network wizard appears.
  • Select VMkernel under Connection Types and click Next.
  • Select Create a virtual switch and click Next.
  • Provide a label for the switch.
  • Select either Use this port group for vMotion or Use this port group for Fault Tolerance logging and click Next.
  • Provide an IP address and subnet mask and click Next.

ftlogging

  • Click Finish.

Networking Example

vMotion and FT Logging can share the same VLAN (configure the same VLAN number in both port groups), but require their own unique IP addresses residing in different IP subnets. However, separate VLANs might be preferred if Quality of Service (QoS) restrictions are in effect on the physical network with VLAN based QoS. QoS is of particular use where competing traffic comes into play, for example, where multiple physical switch hops are used or when a failover occurs and multiple traffic types compete for network resources.

This example uses four port groups configured as follows:

  • VLAN A: Virtual Machine Network Port Group-active on vmnic2 (to physical switch #1); standby on vmnic0 (to physical switch #2.)
  • VLAN B: Management Network Port Group-active on vmnic0 (to physical switch #2); standby on vmnic2 (to physical switch #1.)
  • VLAN C: vMotion Port Group-active on vmnic1 (to physical switch #2); standby on vmnic3 (to physical switch #1.)
  • VLAN D: FT Logging Port Group-active on vmnic3 (to physical switch #1); standby on vmnic1 (to physical switch #2.)

FT3

Instructions for setup

  • Connect to vCenter using the vClient or Web Client
  • Right click the VM you want to use for FT and select Fault Tolerance > Turn on Fault Tolerance

FT4

  • You will get a message as per below

ft5

vSphere Fault Tolerance Configuration Recommendations

VMware recommends that you observe certain guidelines when configuring Fault Tolerance.

  • In addition to non-fault tolerant virtual machines, you should have no more than four fault tolerant virtual machines (primaries or secondaries) on any single host. The number of fault tolerant virtual machines that you can safely run on each host is based on the sizes and workloads of the ESXi host and virtual machines, all of which can vary.
  • If you are using NFS to access shared storage, use dedicated NAS hardware with at least a 1Gbit NIC to obtain the network performance required for Fault Tolerance to work properly.
  • Ensure that a resource pool containing fault tolerant virtual machines has excess memory above the memory size of the virtual machines. The memory reservation of a fault tolerant virtual machine is set to the virtual machine’s memory size when Fault Tolerance is turned on. Without this excess in the resource pool, there might not be any memory available to use as overhead memory.
  • Use a maximum of 16 virtual disks per fault tolerant virtual machine.
  • To ensure redundancy and maximum Fault Tolerance protection, you should have a minimum of three hosts in the cluster. In a failover situation, this provides a host that can accommodate the new Secondary VM that is created.

Analyze HA cluster capacity to determine optimum cluster size

Capture

Cluster Capacity Recommendations

  • How many hosts do you have
  • How many VMs do you have
  • Do you have reservations on your VMs
  • Remember the limit of 32 hosts per cluster
  • Do you have Oracle clustering considerations (CPU Licensing)?
  • Do you have to have separate clusters because of large VMs?
  • By pooling together hosts into larger clusters, DRS is far more efficient at VM placement and providing resource management. It also allows for more efficient HA policy management since the absorption of spare capacity needed for infrequent host failures is now spread out over a larger set of hosts
  • Check all hosts can see shared storage
  • Check your networking. Inconsistency in the network configuration may result in virtual machines losing network connectivity after redistribution, in the event they are moved to a physical host lacking the required VLAN.
  • It’s critical to ensure there is complete network redundancy in all paths between hosts in the cluster. The greatest risk with VMware HA implementations is a false isolation event where an ESX host is incorrectly identified as being offline, triggering an isolation response.
  • DRS load balancing is not instantaneous, so balancing virtual machines with rapidly oscillating load with more consistent VMware HA and DRS Capacity Planning workload characteristics will likely require a larger cluster to ensure a more rapid redistribution response.
  • There are also performance considerations as to the number of hosts that should concurrently access a single LUN, as well as storage IO considerations. Too many hosts with concurrent access to a single LUN can inflict a performance penalty due to LUN-level SCSI reservations associated with virtual machine file operations and LUN metadata updates.
  • Although an HA cluster can contain up to sixteen hosts, recommended cluster sizes generally fall somewhere between eight and twelve, based on the individual organization’s needs.
  • VMware ESX host hardware in the cluster should be as homogeneous as possible, specifically in terms of memory capacity, CPU clock speed, and core count. Because DRS relies on VMotion to migrate running workloads, all hosts must be VMotion compatible
  • It is best to have hosts of the same spec so you don’t create a skewed HA Failover situation.