All posts by Vikas Shitole

About Vikas Shitole

Vikas Shitole is currently working at VMware as Senior Member of Technical Staff (MTS) where he primarily contribute to the VMware vCenter server team which is part of VMware’s R&D organisation. He has been vExpert since last 4 years in row (2014-2017)-title awarded by VMware for significant contribution to VMware community.

Tutorial: Part-1: How to configure & manage Proactive HA using pyVmomi?

Recently I got an opportunity to work on one of the cool vSphere 6.5 features i.e. Proactive HA. As usual, I did explore vSphere APIs introduced to configure and manage Proactive HA and I thought, it would be good to share my learning with you. Since there is lot to share, I have divided this tutorial in 2 parts as follows.

Part-1: What is Proactive HA in brief and how to configure ProactiveHA using pyVmomi.
Part-2: We will discuss on how to simulate a failure so that we can see ProactiveHA in action.

What is Proactive HA in brief?
As we know already, whenever there is a host failure, vSphere HA does restart VMs on alterante hosts inside cluster. vSphere HA works just fine for most of the vSphere environments but there is a minimal downtime as vSphere HA reacts to the failure. On the other hand, proactive HA triggers some meaningful proactive actions even before any host come across any possible failure. One of interesting facts about proactive HA is that, though it can be enabled from vSphere Availability tab, it is in-fact a DRS feature (more on this later). Lets explore Proactive HA APIs to learn further.

Configure ProactiveHA
Managed object HealthUpdateManager enables user to configure and manage ProactiveHA. In fact, these set of APIs are primarily exposed to server vendors & they are supposed to develop a web client plugin using these APIs in order to feed the server health updates to DRS. Once DRS receives these server health updates, it will react to these health updates even before(i.e.proactively) hardware/host gets failed.
Disclaimer: This tutorial is just for lab/educational purpose only.

1. First important thing is to register a health update provider. “RegisterHealthUpdateProvider()” API allows us to register it. Ideally health provider registered should be coming from server vendors. Since this is a tutorial for educational purpose, we will simulate a fake health provider for our understanding, which is not supported by VMware for production use.

2. Once we have health update provider registered, this provider needs to monitor entities for any matching health issues from server. In our case, entities to be monitored by provider are hosts inside the cluster. “AddMonitoredEntities()” is the API that enables user to bind a provider with managed entities such as hosts.

3. So far we talked about registering a provider and adding entities i.e. hosts to be monitored. Now let us go ahead and make this into action using below pyVmomi script.

Note: I have added documentation inside the script itself. Please take a look.

This script i.e. register_provider.py is available on git-hub repo as well


from pyVim.connect import SmartConnect, Disconnect
from pyVmomi import vim
import atexit
import ssl
import sys
import time
#Script to register a health update provider and adding monitored entities
s=ssl.SSLContext(ssl.PROTOCOL_TLSv1)
s.verify_mode=ssl.CERT_NONE
si= SmartConnect(host="10.161.20.30", user="Administrator@vsphere.local", pwd="VMware#123",sslContext=s)
content=si.content

#Cluster where ProactiveHA will be enbaled
cluster_name="ClusterProHA"

# Managed object that exposes all the methods to configure & manage proactiveHA
heath_update_mgr=content.healthUpdateManager

name="ProHAProvider1"  #Name of the provider to be registered

# Building an object with fake/simulated health update
health_update_info=vim.HealthUpdateInfo()
health_update_info.componentType="Power" # Can also be Storage, Memory, Network
health_update_info.description="Power failure Detected"
health_update_info.id="1000"

# Array of health updates, we can have multiple health updates per component type
health_updates = [health_update_info]

#Register a provider with health_updates, it returns a providerid
providerId = heath_update_mgr.RegisterHealthUpdateProvider(name,health_updates)

# Below method helps us to get MOR of the object (vim type) that we passed.
def get_obj(content, vimtype, name):
        obj = None
        container = content.viewManager.CreateContainerView(content.rootFolder, vimtype, True)
        for c in container.view:
                if name:
                        if c.name == name:
                                obj = c
                                break
                        else:
                                obj = None
        return obj

#Cluster object
cluster = get_obj(content,[vim.ClusterComputeResource],cluster_name)
# Hosts inside the cluster
hosts = cluster.host
#Converting array of HostSystem objects to array of managed entities
cluster_entities=vim.ManagedEntity.Array(hosts)

# Adding entities i.e hosts to be monitored
heath_update_mgr.AddMonitoredEntities(providerId,cluster_entities)

#Disconnecting vCenter session
atexit.register(Disconnect, si)

Now that we have registered a provider and added entities to be monitored by this provider, let us verify whether this is really done. Let’s take a look at the script below. The script check_provider_and_entities.py available on my git-hub repo

from pyVim.connect import SmartConnect, Disconnect
from pyVmomi import vim
import atexit
import ssl
import sys
import time
#Script to verify a health update provider and monitored entities
s=ssl.SSLContext(ssl.PROTOCOL_TLSv1)
s.verify_mode=ssl.CERT_NONE
si= SmartConnect(host="10.161.20.30", user="Administrator@vsphere.local", pwd="VMware#123",sslContext=s)
content=si.content

# Managed object that exposes all the methods to configure & manage proactiveHA
health_update_mgr=content.healthUpdateManager

# Listing provider list
provider_list =health_update_mgr.QueryProviderList()

print "Provider Id:"+provider_list[0]

#Quering specific provider
provider_name = health_update_mgr.QueryProviderName(provider_list[0])
print "Provider Name:"+provider_name

#Getting monitored entities by a provider
monitored_entities=health_update_mgr.QueryMonitoredEntities(provider_list[0])
print monitored_entities

#Disconnecting vCenter session
atexit.register(Disconnect, si)

If you take a look, we have used 3 new proactive HA APIs i.e. QueryProviderList(), QueryProviderName() & QueryMonitoredEntities(). Below output confirms that provider is registered and entities are monitored by that provider as expected.

Output:
vmware@localhost:~$ python providerList.py
Provider Id:52 5b d3 2c 0a aa c9 2c-46 4d b8 c2 79 e1 94 c1
Provider Name:ProHAProvider1
(vim.ManagedEntity) [
‘vim.HostSystem:host-21’,
‘vim.HostSystem:host-27’,
‘vim.HostSystem:host-15’
]

Now we are all set for enabling proactive HA on the cluster. Good news is, we can not only enable it using API but also from web client as well. Below is how we can do it using web client.

You can see that Proactive HA can be enabled from “vSphere Availability” tab and note that since this is a DRS feature, user needs to enable DRS first before enabling Proactive HA. Let us now take a look at “Proactive HA Failures and Responses” configuration

I would recommend you to read documentation provided in above screenshot. Below is how finally it looks like.

We enabled Proactive HA using web client. Now let us take a look how to enable the same using API.
This script i.e. enable_proactive_ha.py is available on my git-hub repo.

from pyVim.connect import SmartConnect, Disconnect
from pyVmomi import vim
import atexit
import ssl
import sys
import time

#Script to enable Proactive HA on cluster.

s=ssl.SSLContext(ssl.PROTOCOL_TLSv1)
s.verify_mode=ssl.CERT_NONE
si= SmartConnect(host="10.161.20.30", user="Administrator@vsphere.local", pwd="VMware#123",sslContext=s)
content=si.content

#Cluster where ProactiveHA will be enbaled
cluster_name="ClusterProHA"

# Managed object that exposes all the methods to configure & manage proactiveHA
health_update_mgr=content.healthUpdateManager

# Below method helps us to get MOR of the object (vim type) that we passed.
def get_obj(content, vimtype, name):
        obj = None
        container = content.viewManager.CreateContainerView(content.rootFolder, vimtype, True)
        for c in container.view:
                if name:
                        if c.name == name:
                                obj = c
                                break
                        else:
                                obj = None

        return obj

#Cluster object
cluster = get_obj(content,[vim.ClusterComputeResource],cluster_name)
if not cluster:
        print "Cluster is NOT found, please enter correct cluster name"
        sys.exit()
cluster_spec=vim.cluster.ConfigSpecEx()
drs_enabled = cluster.configuration.drsConfig.enabled

if (not drs_enabled):
        drs_info=vim.cluster.DrsConfigInfo()
        drs_info.enabled = True
        cluster_spec.drsConfig=drs_info
else:
        print "DRS is already enabled, cool"

pro_ha_spec=vim.cluster.InfraUpdateHaConfigInfo()
pro_ha_spec.behavior="Automated"
pro_ha_spec.enabled=True
pro_ha_spec.moderateRemediation="QuarantineMode"
provider_list =health_update_mgr.QueryProviderList()
if(provider_list):
        pro_ha_spec.providers = provider_list  #In our case, it was just one but their can be multiple
else:
        print "Provider is not registered, please do it first before enabling Proactive HA"
        sys.exit()

pro_ha_spec.severeRemediation="MaintenanceMode"
cluster_spec.infraUpdateHaConfig=pro_ha_spec

cluster.ReconfigureComputeResource_Task(cluster_spec, True)

print "Cluster reconfiguration is triggered, please check out, you can track Task object for result"

#Disconnecting vCenter session
atexit.register(Disconnect, si)

You can see existing API i.e. ReconfigureComputeResource_Task() help us enable proactive HA since the same API is responsible for configuring vSphere cluster level features. Also you might have noticed that, in above script, moderateRemediation was set to “QuarantineMode” and severeRemediation was set to “MaintenanceMode, hence if you take a look at web client, it will show remediation mode as “mixed”.

That is all for Part-1. I hope you enjoyed learning this educational tutorial. Please stay tuned for Part-2, where we will simulate a failure to see Proactive HA in action.

Further learning:

1. If you haven’t started with vSphere python SDK i.e. pyVmomi. Here is my tutorial post on the same.

2.For the sake of simplicity, I use to write individual API scripts but I have plan to consolidate above scripts to have good Proactive HA module. If you would like to contribute it, please let me know

3. Very good article by Brian Graf on Proactive HA

4. If you do not prefer Python, as usual William has written a nice PowerCLI module

Simple workaround: Adding a host to an empty EVC cluster fails on latest vCenter patch

This article is motivated by this VMTN thread posted by one of VMware users. I see that several users have reported this usability issue. In this post, I thought to share my understanding about this “empty EVC cluster” behavior along with simple workaround to fix this usability issue.

Update 03/20: Great news! Empty EVC cluster issue discussed in this post is fixed with latest vCenter Patches. With new vCenter patch, empty EVC cluster will NOT expose new cpuids by-default, rather it will expose cpu features based on the first host getting added into EVC cluster. For your learning, once you patch your vCenter server, I would recommend you try below script to understand the new empty EVC cluster behavior.

1. What is the issue?

Users are NOT able to add a host into an empty EVC cluster after applying latest vCenter patch, which was released as part of Hypervisor-Assisted Guest Mitigation on 9th Jan, 2018. In order to explore this further, I created a empty EVC cluster on vCenter 6.5 U1e as shown below.

You can see, I have created empty EVC cluster, where EVC mode configured is “Intel-IvyBridge”. Now I tried adding a host, where corresponding ESXi patch is NOT applied and as posted on VMTN thread, I see below error on web client.

 2. Why does it fail with this vCenter 6.5 U1e patch?

You might know that, as part of VMware patches released for Hypervisor-Assisted Guest Mitigation, there are three new cpuids got exposed i.e. cpuid.IBRS , cpuid.IBPB & cpuid.STIBP. Now we need to know whether these new cpuids are exposed by the “empty EVC cluster” that we just created but you might be wondering how to go about it? It is fairly simple to know it by using one of EVC API properties as posted in my tutorial post on EVC vSphere APIs. As part of section #4 of that tutorial i.e. “Exploring EVC Cluster state”, I had written a pyVmomi script to get the EVC cluster state i.e. getEVCClusterState.py. I little modified this script to know whether new cpuids are exposed by cluster or not. Below is the code snippet.

#Cluster object for empty EVC cluster
cluster = get_obj(content,[vim.ClusterComputeResource],cluster_name)
#EVCManager which exposes EVC APIs
evc_cluster_manager=cluster.EvcManager()

evc_state=evc_cluster_manager.evcState
current_evcmode_key= evc_state.currentEVCModeKey

if(current_evcmode_key):
        print "Current EVC Mode::"+current_evcmode_key
else:
        print "EVC is NOT enabled on the cluster"
        quit()

#getting feature capabilities available on cluster
feature_capabilities = evc_state.featureCapability

flag=False
for capability in feature_capabilities:

        if(capability.key=="cpuid.STIBP" and capability.value=="1"):
                print "Found new cpuid::"+ capability.key
                flag=True

        if(capability.key=="cpuid.IBPB" and capability.value=="1"):
                print "Found new cpuid::"+ capability.key
                flag=True

        if(capability.key=="cpuid.IBRS" and capability.value=="1"):
                print "Found new cpuid::"+ capability.key
                flag=True
if(not flag):
        print "No new cpubit found"

Once I executed above script on “empty EVC cluster” and I see output as follows

Output:
vmware@localhost:~$ python emptyEVCCluster.py
Current EVC Mode::intel-ivybridge
Found new cpuid::cpuid.IBPB
Found new cpuid::cpuid.IBRS
Found new cpuid::cpuid.STIBP
vmware@localhost:~$

Output clearly shows that new cpuids are exposed on the “empty EVC cluster” that we created on latest vCenter patch. This concludes that when you try to add a non-patched host into this cluster, it will fail since that host does NOT support these new cpuids. On the other hand, if you have applied corresponding ESXi patch (which is pulled back at the moment), then you will not face this issue as new cpuids are available on that patched host. Now that you understood this behavior, let us take a look at the simple workaround to fix this issue.

3. What is the workaround?

I understand, this is a problem from usability perspective but good news is that we have very simple workaround available i.e. Instead of upfront enabling EVC on the empty cluster, you can create non-EVC cluster first , add all possible hosts into it and finally enable EVC as per available EVC mode. If you ask me, it is always good idea to create non-EVC cluster and only after adding all possible hosts, we should finally enable EVC on cluster.

I would also recommend you to read “vMotion and EVC Information” section from VMware KB to understand EVC and vMotion behavior post applying these patches.

4. Some useful resources on EVC

1. Part-1: Managing EVC using pyVmomi
2. Part 2: Managing EVC using pyVmomi
3. Tutorial on getting started pyVmomi

I hope you enjoyed this post, let me know if you have any questions/doubts.

Tutorial: Part-2 : How to Manage EVC using vSphere Python SDK pyVmomi?

In part-1, we explored EVC enable, disable APIs & some important EVC properties using pyVmomi. In part-2, we would explore left out EVC APIs from part-1 i.e.CheckConfigureEvcMode_Task() & CheckAddHostEvc_Task(). In addition, we will also take a look at some more important EVC properties required to manage EVC end to end.

1. Checking whether EVC can be configured on existing cluster or not?
CheckConfigureEvcMode_Task() is responsible for checking exactly the same. If you have existing cluster with several hosts and if you would like to evaluate whether EVC can be enabled on cluster or not on particular EVCMode key, this API is really handy. If it is not possible to enable EVC on particular cluster, this API will return not only the set of reasons why it can fail to configure EVC but also the set of hosts those are causing it to fail. Before we start, below are the set of hosts present in cluster already.

vmware@localhost:~$ python getMaxEVCModeonHost.py
ClusterName::vThinkBVMCluster
10.160.20.30::intel-broadwell
10.160.20.31::intel-sandybridge
vmware@localhost:~$

To start with, the way we did in part-1, we will check whether EVC can be enabled on “intel-broadwell” EVCMode key. As we learned in last post, EVC should not be able to configure on this cluster with EVCMode “intel-broadwell”. Let us see whether API properly returns right reason and host that is causing it.

Below script is available on my git-hub repo as well

from pyVim.connect import SmartConnect, Disconnect
from pyVmomi import vim
import atexit
import ssl
import sys
import time

#Script to check whether EVC can be enabled on cluster with given EVCMode

s=ssl.SSLContext(ssl.PROTOCOL_TLSv1)
s.verify_mode=ssl.CERT_NONE
si= SmartConnect(host="10.160.50.60", user="Administrator@vsphere.local", pwd="VMware#12",sslContext=s)
content=si.content
cluster_name="vThinkBVMCluster";

# Below method helps us to get MOR of the object (vim type) that we passed.
def get_obj(content, vimtype, name):
        obj = None
        container = content.viewManager.CreateContainerView(content.rootFolder, vimtype, True)
        for c in container.view:
                if name:
                        if c.name == name:
                                obj = c
                                break
                        else:
                                obj = None                          
        return obj

#Cluster object
cluster = get_obj(content,[vim.ClusterComputeResource],cluster_name)
evc_cluster_manager=cluster.EvcManager()

print "ClusterName::"+cluster.name

task=evc_cluster_manager.CheckConfigureEvcMode_Task("intel-broadwell")
time.sleep(5)
checkResult= task.info.result

if(checkResult):
         print "EVC can not be enabled on this cluster, please take look at below reasons and hosts causing this issue"
        for result in checkResult:
                print result.error.msg
                for h in result.host:
                        print h.name
                print "---------------------"
else:
        print "EVC can be successfully enabled on the cluster with no issues"

atexit.register(Disconnect, si)

vmware@localhost:~$ python checkEVC.py
ClusterName::vThinkBVMCluster
EVC can not be enabled on this cluster, please take look at below reasons and hosts causing this issue
The host’s CPU hardware does not support the cluster’s current Enhanced vMotion Compatibility mode. The host CPU lacks features required by that mode.
10.160.20.31
———————

isn’t this error matching with this screenshot from Part-1?

Note: If you notice on line #38, CheckConfigureEvcMode_Task() API returns ClusterEVCManagerCheckResult only when EVC can NOT be configured on the cluster.

Now I did powerON one of the VMs on host, which has max EVCMode as “intel-broadwell” and executed above script but this time passed EVCMode key as “intel-sandybridge”. Let us take a look at output.

Output:
vmware@localhost:~$ python checkEVC.py
ClusterName::vThinkBVMCluster
EVC can not be enabled on this cluster, please take look at below reasons and hosts causing this issue
The host cannot be admitted to the cluster’s current Enhanced vMotion Compatibility mode. Powered-on or suspended virtual machines on the host may be using CPU features hidden by that mode.
10.160.20.30
———————
vmware@localhost:~$

You can see, EVC configuration failed since one of VM was powered ON, which is using some cpu features those are NOT available on “intel-sandybridge” EVC mode. This is expected and error is exactly matching with web client screenshot from Part-1.

Now I powered-off the VM residing on “intel-broadwell” based host & Powered-ON VM on host, which support max EVCMOde as “intel-sandybridge”. Finally executed same checkEVC.py script and below is the output.

Output:
vmware@localhost:~$ python checkEVC.py
ClusterName::vThinkBVMCluster
EVC can be succesfully enabled on the cluster with no issues
vmware@localhost:~$

wasn’t output cool? Note that VM was up on host with “intel-sandybridge” host and EVCMode used was also “intel-sandybridge”, hence EVC will be configured successfully. Now let us move on to next EVC API.

2. Checking whether host can be added into existing EVC enabled cluster or not?
CheckAddHostEvc_Task() API allows user to check exactly the same. This API accepts HostSpec as paramter for the host to be checked and below is the code snippet. I will leave it to you in order to try this API in your environment.

host_conn_spec=vim.host.ConnectSpec()
host_conn_spec.force=True
host_conn_spec.hostName=host.name
host_conn_spec.userName=host_user
host_conn_spec.password=host_pass
thumb_print=host.summary.config.sslThumbprint
host_conn_spec.sslThumbprint=thumb_print
print host_conn_spec
task=evc_cluster_manager.CheckAddHostEvc_Task(host_conn_spec)

That is all about EVC APIs. I hope Part-1 & Part-2 have given you good insight into how to play around EVC APIs. Stay tuned for my next post. Please comment if you have any query.

Tutorial: How to manage Enhanced vMotion Compatibility (EVC) using vSphere Python SDK pyVmomi? Part-I

As part of recent security issues i.e. Spectre & Meltdown, I got an opportunity to play around  one of famous vSphere features i.e. Enhanced vMotion Compatibility (EVC) and  I thought this is the right time to explore EVC vSphere APIs . I see that EVC APIs are made public as part of vSphere 6.0 release though feature itself was introduced in vSphere 4.0. Since there is lot to learn about EVC vSphere APIs, I thought it is better to divide this topic in 2 parts. These parts will be kind of tutorial on EVC APIs and at the same time, we will touch upon EVC functionality as well. Before we start exploring EVC APIs, it is important that you understand what EVC is all about & why one needs to enable it on cluster? For quick learning, I think, no better resource than this EVC FAQ KB. In short, EVC makes it possible to mix different generations of CPU servers inside a cluster, which enables vMotion across these servers. Once EVC is enabled on vSphere cluster level, it ensures that all the servers across different CPU generation exposes same cpuid bits to its virtual machines.

When it comes to EVC APIs, ClusterEVCManager is the major managed object, which exposes 4 important methods as follows.

  •  ConfigureEvcMode_Task()
  •  DisableEvcMode_Task()
  • CheckConfigureEvcMode_Task()
  • CheckAddHostEvc_Task()

1. Getting max EVCMode key

Before we look into above methods, we need to get max EVCMode supported by each ESXi host to be added into EVC enabled cluster. Let us take a look at simple pyVmomi script for the same.

Below script is available on my github repo getMaxEVCMode.py

#Script to get Max EVC Mode supported on all the hosts in the cluster

from pyVim.connect import SmartConnect, Disconnect
from pyVmomi import vim
import atexit
import ssl
import sys

s=ssl.SSLContext(ssl.PROTOCOL_TLSv1)
s.verify_mode=ssl.CERT_NONE
si= SmartConnect(host="10.160.50.60", user="Administrator@vsphere.local", pwd="VMware#12",sslContext=s)
content=si.content

# Your cluster name
cluster_name="vThinkBVMCluster"

# Below method helps us to get MOR of the object (vim type) that we passed.
def get_obj(content, vimtype, name):
        obj = None
        container = content.viewManager.CreateContainerView(content.rootFolder, vimtype, True)
        for c in container.view:
                if name:
                        if c.name == name:
                                obj = c
                                break
                        else:
                                obj = None
        return obj

#Cluster object
cluster = get_obj(content,[vim.ClusterComputeResource],cluster_name)
print "ClusterName::"+cluster.name

# Get all the hosts available inside cluster
hosts = cluster.host

#Iterate through each host to get MaxEVC mode supported on the host
for host in hosts:

        host_max_evcmode = host.summary.maxEVCModeKey

        if host_max_evcmode == None:
                print host.name+" does not support EVC"
        else:
                print host.name+"::"+host_max_evcmode

#Disconnect the vCenter server session.
atexit.register(Disconnect, si)

Above script takes cluster name as input, get all the hosts inside the cluster and iterate through each host in order to get max EVCMode required to enable the EVC on right mode. Line #37 is what gets us “maxEVCModeKey”. Let us take look at how output looks like

Output :
vmware@localhost:~$ python getMaxEVCModeonHost.py
ClusterName::vThinkBVMCluster
10.160.20.30::intel-broadwell
10.160.20.31::intel-sandybridge
vmware@localhost:~$

You could see, there are 2 hosts inside the cluster and their max EVCMode keys are intel-broadwell and intel-sandybridge respectively. We need to choose right max EVCMode key to enable EVC on the cluster.

You may be wondering, can EVC modes supported per host be viewed from vSphere web client? Yes, it is, please take a look at below screenshot.

2. Enable EVC on cluster

Now that we have got max EVC mode per host, let us take a look at EVC API responsible to enable EVC on the cluster. i.e. ConfigureEvcMode_Task(). This API require EVC mode to be passed as parameter.

To start with, we will pass max EVCMode as “intel-broadwell” and see what happens. Lets take a look at script below.

Below script is available on my github repo enableEVC.py

from pyVim.connect import SmartConnect, Disconnect
from pyVmomi import vim
import atexit
import ssl
import sys

#Script to enable/disable EVC on cluster

s=ssl.SSLContext(ssl.PROTOCOL_TLSv1)
s.verify_mode=ssl.CERT_NONE
si= SmartConnect(host="10.160.50.60", user="Administrator@vsphere.local", pwd="VMware#12",sslContext=s)
content=si.content

#Your cluster input
cluster_name="vThinkBVMCluster"

# Below method helps us to get MOR of the object (vim type) that we passed.
def get_obj(content, vimtype, name):
        obj = None
        container = content.viewManager.CreateContainerView(content.rootFolder, vimtype, True)
        for c in container.view:
                if name:
                        if c.name == name:
                                obj = c
                                break
                        else:
                                obj = None
        return obj

#Cluster object
cluster = get_obj(content,[vim.ClusterComputeResource],cluster_name)

# Major EVC cluster manager object
evc_cluster_manager=cluster.EvcManager()

print "ClusterName::"+cluster.name

# Configure EVC mode by passing EVCMode
task=evc_cluster_manager.ConfigureEvcMode_Task("intel-broadwell")

atexit.register(Disconnect, si)

Notice the line #40, where method is called to enable EVC. Right after executing above script, I looked into web client to see whether EVC is really enabled or not and below is what I observed.

Error displayed above is expected since we are enabling EVC on cluster with “intel-broadwell” EVCMode, which has additional cpuid bits (CPU feature set) those are NOT available on other host inside the cluster. Since “intel-broadwell” is latest intel CPU model, “intel-sandybridge” host does not have new features available. In other words, host with “intel-sandybridge” EVCMode has all the cpu features are available on “intel-broadwell” based host but not the vice-versa, hence we can only enable EVC on cluster with “intel-sandybridge or lower EVCMode.

Now before I execute above script with “intel-sandybridge” EVCMode, I powered on all the VMs available inside the cluster, once VMs are powered ON, I executed above script by editing EVCMode as “intel-sandybridge” on line #40. Since “intel-sandybridge” cpu feature set is available on “intel-broadwell”, you might be hoping that EVC will be successfully enabled on cluster. Let us take a look at web client screenshot.

You could see EVC is NOT enabled again. You might be wondering why is EVC not enabled even though EVCMode is right? As error states, since cluster has Powered-ON VMs those can potentially be using CPU features, which can not be available after enabling EVC on “intel-sandybridge” mode. Reason is EVC will mask additional CPU features (from broadwell host) to have same CPU features across all the hosts inside cluster. I hope you are following.

Now I powered-off and executed the script to enable EVC on “intel-sandybridge” mode. Let us take a look at below screenshot.

You can see EVC is enabled successfully, isn’t it cool?

Note: It is recommended to enable EVC on cluster with min of all hosts maxEVCMode key Ex. min (intel-sandybridge, intel-broadwell) = intel-sandybridge

3. Disabling EVC on cluster

Disabling EVC on cluster is fairly simple using DisableEvcMode_Task() , we have to just replace line #40 with below line.

task=evc_cluster_manager.DisableEvcMode_Task()

After making change as specified above, I confirmed from web client that EVC is successfully disabled. Please take a look at below screenshot.

EVC disabled

You can use Task object returned by ConfigureEvcMode_Task() & DisableEvcMode_Task() methods for tracking the task progress, any errors, state etc.

Now that you learned how to configure, enable & disable EVC on cluster, let us now learn how to know what cpu features are masked by EVC, what cpu features are available on each hosts inside EVC enabled cluster. If you ask me, again it is very simple.

4. Exploring EVC Cluster state

How to get current EVCMode enabled on cluster ? How to know whether EVC is disabled on cluster or not? How to get cpu features available & features masked on EVC cluster? All these questions are answered as part of below script.

Below script available on my github repo getEVCClusterState.py

from pyVim.connect import SmartConnect, Disconnect
from pyVmomi import vim
import atexit
import ssl
import sys
#Script to get Max EVC Mode supported on all the hosts in the cluster
s=ssl.SSLContext(ssl.PROTOCOL_TLSv1)
s.verify_mode=ssl.CERT_NONE
si= SmartConnect(host="10.160.50.60", user="Administrator@vsphere.local", pwd="VMware#12",sslContext=s)
content=si.content
cluster_name="vThinkBVMCluster"

# Below method helps us to get MOR of the object (vim type) that we passed.
def get_obj(content, vimtype, name):
        obj = None
        container = content.viewManager.CreateContainerView(content.rootFolder, vimtype, True)
        for c in container.view:
                if name:
                        if c.name == name:
                                obj = c
                                break
                        else:
                                obj = None
        return obj

#Cluster object
cluster = get_obj(content,[vim.ClusterComputeResource],cluster_name)
evc_cluster_manager=cluster.EvcManager()

evc_state=evc_cluster_manager.evcState
current_evcmode_key= evc_state.currentEVCModeKey

if(current_evcmode_key):
        print "Current EVC Mode::"+current_evcmode_key
else:
        print "EVC is NOT enabled on the cluster"
        quit()

feature_capabilities = evc_state.featureCapability

for capability in feature_capabilities:
        print "Feature Capability\n"
        print capability.featureName
        print capability.key
        print capability.value
        print "-------------"

features_masked = evc_state.featureMask

for mask in features_masked:
        print "Feature Masked\n"
        print mask.featureName
        print mask.key
        print mask.value
        print "-------------"
atexit.register(Disconnect, si)

That is all for Part-1, I hope you enjoyed.

Update : Part-2 is ready as well, where we will explore remaining EVC APIs i.e. CheckConfigureEvcMode_Task() & CheckAddHostEvc_Task().

For more learning, EVC official documentation is here