The last sentence in the second paragraph of the slide notes states:
On the slide, Blade Chassis A, Blade Chassis B, and ISV-Licensed are host DRS groups.Correct:
This description refers to something that is actually not displayed anywhere in the slide. This sentence is a leftover from previous editions of this course.
While describing the CPU vendors' supporting technologies for EVC, the second sentence in the slide notes states:
EVC automatically configures hosts whose CPUs feature Intel FlexMigration and AMD-V Extended Migration technologies to be compatible with vSphere vMotion with hosts that use older CPUs.Correct:
The actual complete Intel's marketing name for the technology is Intel VT FlexMigration.Source:
VMware White Papers.
While describing how to enable EVC, the first sentence in the slide notes states:
In the VMware EVC section of the New Cluster dialog box, you can enable Enhanced vMotion Compatibility (EVC).Correct:
In the vSphere Web Client, shown in the slide graphic, the mentioned section is actually called EVC only.
While describing how to enable vSphere DRS, the first paragraph in the slide notes states:
Type a descriptive name for your cluster and select the Turn On VMware DRS check box.Correct:
In the vSphere Web Client, shown in the slide graphic, the mentioned check box is actually called Turn On only and is available within the DRS section.
Network port tcp/44046 is not the only one being used by the vSphere Replication Appliance.
During the initial replication traffic, in example, the appliance uses port tcp/31031 for communicating between the ESXi host on the primary, protected site and the vSphere Replication server in the vSphere Replication appliance at the recovery site.Source:
VMware Knowledge Base articles.
When describing where to find information about Fault Tolerant virtual machines resource utilization, the second paragraph in the slide notes state:
You can view information about both the primary and the secondary virtual machines in the Fault Tolerance pane in the virtual machine’s Summary tab or in the Virtual Machines tab of a host or cluster.1. Correct:
There is no Virtual Machine tab for hosts or clusters in the vSphere Web Client. Even if you look at the Related Objects tab for hosts or clusters, the Virtual Machines link will only show the primary virtual machine, not the secondary.
The only place where you can actually find information about both the primary and the secondary virtual machines side by side is on the cluster Monitor tab, by clicking the Resource Allocation link and reviewing any of the available sections: CPU, Memory and Storage.
While describing the various fields in the virtual machine Fault Tolerance panel, the penultimate bulleted list item in the slide notes states:
Secondary VM Lag Time indicates the latency between the primary and the secondary virtual machines.2. Correct:
In the vSphere Web Client, the above mentioned field has a different label name. Hence, the phrase should be better reworded accordingly:
vLockStep Interval indicates the latency between the primary and the secondary virtual machines.
While describing the master host election process, slide notes state:
If all slave hosts have equal datastore access, the election process selects a new master host using the highest numbered managed object ID (MOID) assigned by vCenter Server when the host was added to the vCenter Server inventory.Correct:
Actually, according to Duncan Epping's article "HA Deepdive" on his blog Yellow-Bricks:
If two or more hosts have the same number of datastores connected, the one with the highest Managed Object Id will be chosen. This however is done lexically; meaning that 99 beats 100 as 9 is larger than 1.Info:
Duncan Epping is - taking his self-description on his Twitter account (@DuncanYB) as of the day of the publication of this article - "Principal Architect @ VMware R&D. Start-up Advisor. Author of virtualization blog yellow-bricks.com. Author of vSphere Clustering Deepdive. Runner".Source:
The first sentence in the slide notes states:
Datastores are used as a backup communication channel to detect virtual machine and host heartbeats.Correct:
The highlighted portion of the above sentence is very ambiguous. To me, it seems to imply that the virtual machines heartbeat mechanism (provided by the VMware Tools) can failover to a datastore heartbeat-like capability.
This is - AFAIK - a nonsense because:
In vCenter Server 4.0, VMware introduced an additional disk I/0 status check, after the virtual machine heartbeat fails, to prevent accidental VM resets. This check ensures to wait for 120 seconds (by default) of no disk I/O activity before the reset takes place. The das.iostatsInterval advanced HA attribute can further customize the time the host is going to wait before actually resetting the VM.
This disk I/0 status check might be what the slide notes are referring to as "a backup communication channel to detect virtual machine heartbeats".
VMware Knowledge Base articles.
When describing the Datastore Heartbeating failure detection mechanism, slide notes provide a slightly messy statement:
Using datastore heartbeating, the master host determines whether the other host has failed, is part of a network partition, or network isolation has occurred. If datastore heartbeating from the host stops, then the host considers the host failed.Correct:
For clarification, the highlighted sentence might be re-worded as follows:
If datastore heartbeating from the host stops, then the master host considers that host failed.