Category: VMware

ESXi is the hypervisor in a vSphere environment. The hypervisor provides physical hardware resources dynamically to virtual machines as needed to support the operation of the virtual machines. The hypervisor allows virtual machines to operate with a degree of independence from the underlying physical hardware. For example, a virtual machine can be moved from one physical host to another, or its virtual disks can be moved from one type of storage to another, without affecting the functioning of the virtual machine.
Because virtual machines are decoupled from specific underlying physical hardware, virtualization allows you to consolidate physical computing resources such as CPUs, memory, storage, and networking into pools of resources that can be dynamically and flexibly made available to virtual machines. With appropriate management software, such as vCenter Server, you can also use a number of features that increase the availability and security of your virtual infrastructure.

Networking Issues fixed in the latest release 6.5 U1d

tapasmahanta124Leave a comment
  • Host profile might fail to extract after import of a VMware vSphere Distributed Switch from a backup fileIf you import a vSphere Distributed Switch (VDS) by previous backup file with Preserve original distributed switch and port group identifiers option selected, in case vCenter Server restarts, it does not load the port group from the database correctly, and the operation to extract the host profile might fail. You might see an error similar to A specified parameter was not correct: dvportgroup-XXXXX Error: specified value.

    This issue is resolved in this release.

    NOTE: If you have already encountered this issue, after you upgrade to vCenter Server 6.5 Update 1d, you must disconnect and reconnect the respective host.

  • vNICs of virtual machines might lose connection after a refresh of VMware Horizon view poolThe virtual network interface cards (vNIC) of virtual machines might lose connection after a refresh of a VMware Horizon view pool, because while VMs shut down and power on, the vCenter Server and the ESXi host might be out of sync, which might break the existing connection between vNICs and ephemeral port groups.

    This issue is resolved in this release.

  • vMotion of virtual machines with imported ephemeral port groups might fail as ports are not created after migrationYou might see vMotion of virtual machines with imported ephemeral port groups, or a VMware vSphere Distributed Switch (VDS) with such port groups, fail with an error similar to A general system error occurred: vim.fault.NotFound, because the ports might not be created after the migration.

    This issue is resolved in this release.

    NOTE: If you already can not migrate virtual machines due to this issue, after the upgrade to vCenter Server Update 1d you must delete the imported ephemeral port groups or DVS with such port groups and reimport them.

  • vCenter Server does not accept SNMP users with non-alphanumeric charactersWith this fix you can create users on vCenter Server SNMP configuration with non-alphanumeric characters. Previously, only SNMP configurations for ESXi allowed users with non-alphanumeric characters.

    This issue is resolved in this release.

  • vSphere Web Client might show error in vSphere Distributed Switch topology after a restart of vpxd due to outdated Link Aggregation Groups datavSphere Web Client might show an error in the vSphere Distributed Switch topology after a restart of vpxd due to outdated Link Aggregation Groups (LAG) data, as the vCenter Server database might not be updated with data for physical adapters added to the LAG before the restart, and the daemon might not be able to find it.

    This issue is resolved in this release.

    NOTE: If you already face the issue, you must reassign the physical adapters to the LAG.

Please find the link to download 6.5 U1d :https://my.vmware.com/web/vmware/details?downloadGroup=VC65U1D&productId=614&rPId=20189&src=so_5a314d05e49f5&cid=70134000001SkJn

Storage and VSAN related Issues fixed in 6.5 U1d

tapasmahanta124Leave a comment

Storage Issue:

++++++++++

  • vSphere Web Client might not properly display storage devices after EMC Powerpath 6.0.1. installationvSphere Web Client might not properly display storage devices after EMC Powerpath 6.0.1 installation if the ESXi host has only LUNs and the host is set up to boot from a SAN.This issue is resolved in this release.
  • Datastores might falsely appear as incompatible for a storage policy that includes I/O filter rulesWhen you create or edit an existing storage policy, containing I/O filter common rules, and while checking for storage compatibility, you might observe messages like:Datastore does not match current VM policy or Datastore does not satisfy compatibility since it does not support one or more required properties

    Some of the datastores that you expect to be compatible, might appear in the incompatible list when you are checking for storage compatibility. This might also happen when you provision a virtual machine with a storage policy, containing I/O filter rules.This issue is resolved in this release.

  • Map Disk Region task might fill up the vCenter Server database task tableThe Map Disk Region task might alone fill up the vpx_task table in the vCenter Server database, which might cause vCenter Server to become unresponsive or other performance issues.

vSAN Issues:

+++++++++++

  • vSAN iSCSI messages might flood the Tasks view of vSphere Web ClientIf you upgrade a vSAN cluster from a vSphere 6.0 environment to a vSphere 6.5 environment, a message like Edit vSAN iSCSI target service in cluster might flood the Tasks view in the vSphere Web Client, even if the vSAN iSCSI feature is not enabled in this cluster.This issue is resolved in this release.
  • New icon for vSAN witness appliancesThis release introduces a new icon for vSAN witness appliances. When you deploy a vSAN witness appliance, you will see a nested host with a new icon in the UI, which indicates that this host can only be used as a witness in a stretched cluster.This issue is resolved in this release.
  • vSAN Health Service logs might eat up all log storage space in vCenter Server on WindowsvSAN Health Service logs might eat up all log storage space in vCenter Server on Windows if log rotation coincides with a running task for collecting support bundle or phone home data for Customer Experience Improvement Plan (CEIP).This issue is resolved in this release.
  • vSphere Update Manager baselines might change from patch to upgrade when only one node in a cluster is remediatedvSAN build recommendation for system baselines and baseline groups for use with vSphere Update Manager might not work if there is a vCenter Server system-wide http proxy. With this fix, vSAN build recommendations in a system-wide http proxy set up are as available and consistent as the vSAN build recommendations created with direct Internet connection.

Download the release from : https://my.vmware.com/web/vmware/details?downloadGroup=VC65U1D&productId=614&rPId=20189&src=so_5a314d05e49f5&cid=70134000001SkJn

Troubleshooting a Performance issue

tapasmahanta124Leave a comment

This is pain point for most of us on how to isolate and understand who is the culprit on performance issue. I will try to add all the points together and summarize .

Symptoms:
++++++++++
>>Services running in guest virtual machines respond slowly.
>>Applications running in the guest virtual machines respond intermittently.
>>The guest virtual machine may seem slow or unresponsive.

There are 4 major things which deal with the performance:

1: CPU
2: Memory
3: Storage
4: Networking

1:CPU:

>>Use the esxtop command to determine if the ESXi/ESX server is being overloaded.
>>Examine the load average on the first line of the command output.
A load average of 1.00 means that the ESXi/ESX Server machine’s physical CPUs are fully utilized, and a load average of 0.5 means that they are half utilized. A load average of 2.00 means that the system as a whole is overloaded.
>>Examine the %READY field for the percentage of time that the virtual machine was ready but could not be scheduled to run on a physical CPU.

For more info please follow : https://kb.vmware.com/s/article/1033115?r=2&KM_Utility.getArticleLanguage=1&KM_Utility.getArticle=1&KM_Utility.getGUser=1&KM_Utility.getArticleData=1&Quarterback.validateRoute=1

If the load average is too high, and the ready time is not caused by CPU limiting, adjust the CPU load on the host. To adjust the CPU load on the host, either:

Increase the number of physical CPUs on the host
OR
Decrease the number of virtual CPUs allocated to the host. To decrease the number of virtual CPUs allocated to the host, either:

Reduce the total number of CPUs allocated to all of the virtual machines running on the ESX host. For more information, see Determining if multiple virtual CPUs are causing performance issues (1005362).
OR
Reduce the number of virtual machines running on the host.

2:Memory:

>>Use the esxtop command to determine whether the ESXi/ESX server’s memory is overcommitted.
>>Examine the MEM overcommit avg on the first line of the command output. This value reflects the ratio of the requested memory to the available memory, minus 1.

Examples:

If the virtual machines require 4 GB of RAM, and the host has 4 GB of RAM, then there is a 1:1 ratio. After subtracting 1 (from 1/1), the MEM overcommit avg field reads 0. There is no overcommitment and no extra RAM is required.
If the virtual machines require 6 GB of RAM, and the host has 4 GB of RAM, then there is a 1.5:1 ratio. After subtracting 1 (from 1.5/1), the MEM overcommit avg field reads 0.5. The RAM is overcommited by 50%, meaning that 50% more than the available RAM is required.

>>Determine whether the virtual machines are ballooning and/or swapping.

To detect any ballooning or swapping:

++Run esxtop.
++Type m for memory
++Type f for fields
++Select the letter J for Memory Ballooning Statistics (MCTL)
++Look at the MCTLSZ value.

MCTLSZ (MB) displays the amount of guest physical memory reclaimed by the balloon driver.

++Type f for Field
++Select the letter for Memory Swap Statistics (SWAP STATS).
++Look at the SWCUR value.

SWCUR (MB) displays the current Swap Usage.

3:Storage:

To determine whether the poor performance is due to storage latency:

>>Determine whether the problem is with the local storage. Migrate the virtual machines to a different storage location.
>>Reduce the number of Virtual Machines per LUN.
>>Look for log entries in the Windows guests that look like this:

The device, \Device\ScsiPort0, did not respond within the timeout period.
>>Using esxtop, look for a high DAVG latency time
>>Determine the maximum I/O throughput you can get with the iometer command.
>>Compare the iometer results for a VM to the results for a physical machine attached to the same storage.
>>Check for SCSI reservation conflicts.
>>If you are using iSCSI storage and jumbo frames, ensure that everything is properly configured.
>>If you are using iSCSI storage and multipathing with the iSCSI software initiator, ensure that everything is properly configured.

4:Network:

Network performance can be highly affected by CPU performance. Rule out a CPU performance issue before investigating network latency.

To determine whether the poor performance is due to network latency:

>>Test the maximum bandwidth from the virtual machine with the Iperf tool. This tool is available from https://github.com/esnet/iperf

Note: VMware does not endorse or recommend any particular third-party utility.

While using Iperf, change the TCP windows size to 64 K. Performance also depends also on this value. To change the TCP windows size:

On the server side, enter this command:

#iperf -s

On the client side, enter this command:

#iperf.exe -c sqlsed -P 1 -i 1 -p 5001 -w 64K -f m -t 10 900M

 

Some additional Information on ESXTOP:
++++++++++++++++++++++++++++++++++++++

Configuring monitoring using esxtop:
====================================
To monitor storage performance per HBA:

>>Start esxtop by typing esxtop at the command line.
>>Press d to switch to disk view (HBA mode).
>>To view the entire Device name, press SHIFT + L and enter 36 in Change the name field size.
>>Press f to modify the fields that are displayed.
>>Press b, c, d, e, h, and j to toggle the fields and press Enter.
>>Press s and then 2 to alter the update time to every 2 seconds and press Enter.

To monitor storage performance on a per-LUN basis:

>>Start esxtop by typing esxtop from the command line.
>>Press u to switch to disk view (LUN mode).
>>Press f to modify the fields that are displayed.
>>Press b, c, f, and h to toggle the fields and press Enter.
>>Press s and then 2 to alter the update time to every 2 seconds and press Enter.

 

For more information please follow the VMware KB : https://kb.vmware.com/s/article/1008205

 

VixDiskLib API

tapasmahanta124Leave a comment

On ESXi hosts, virtual machine disk (VMDK) files are usually located under one of the /vmfs/volumes, perhaps on shared storage. Storage volumes are visible from the vSphere Client, in the inventory of hosts and clusters. Typical names are datastore1 and datastore2. To see a VMDK file, click Summary > Resources > Datastore, right-click Browse Datastore, and select a virtual machine.
On Workstation, VMDK files are stored in the same directory with virtual machine configuration (VMX) files, for example, /path/to/disk on Linux or C:\My Documents\My Virtual Machines on Windows.
VMDK files store data representing a virtual machine’s hard disk drive. Almost the entire portion of a VMDK file is the virtual machine’s data, with a small portion allotted to overhead.

Initialize the Library:
+++++++++++++++++

VixDiskLib_Init() initializes the old virtual disk library. The arguments majorVersion and minorVersion represent the VDDK library’s release number and dot-release number. The optional third, fourth, and fifth arguments specify log, warning, and panic handlers. DLLs and shared objects may be located in libDir.
VixError vixError = VixDiskLib_Init(majorVer, minorVer, &logFunc, &warnFunc, &panicFunc, libDir);
You should call VixDiskLib_Init() only once per process because of internationalization restrictions, at the beginning of your program. You should call VixDiskLib_Exit() at the end of your program for cleanup. For multithreaded programs you should write your own logFunc because the default function is not thread safe.
In most cases you should replace VixDiskLib_Init() with VixDiskLib_InitEx(), which allows you to specify a configuration file.

Virtual Disk Types:
++++++++++++++++

The following disk types are defined in the virtual disk library:
>>>
VIXDISKLIB_DISK_MONOLITHIC_SPARSE – Growable virtual disk contained in a single virtual disk file. This is the default type for hosted disk, and the only setting in the Virtual Disk API .
>>>
VIXDISKLIB_DISK_MONOLITHIC_FLAT – Preallocated virtual disk contained in a single virtual disk file. This takes time to create and occupies a lot of space, but might perform better than sparse.
>>>
VIXDISKLIB_DISK_SPLIT_SPARSE – Growable virtual disk split into 2GB extents (s sequence). These files can to 2GB, then continue growing in a new extent. This type works on older file systems.
>>>
VIXDISKLIB_DISK_SPLIT_FLAT – Preallocated virtual disk split into 2GB extents (f sequence). These files start at 2GB, so they take a while to create, but available space can grow in 2GB increments.
>>>
VIXDISKLIB_DISK_VMFS_FLAT – Preallocated virtual disk compatible with ESX 3 and later. Also known as thick disk. This managed disk type is discussed in Managed Disk and Hosted Disk.
>>>
VIXDISKLIB_DISK_VMFS_SPARSE – Employs a copy-on-write (COW) mechanism to save storage space.
>>>
VIXDISKLIB_DISK_VMFS_THIN – A Growable virtual disk that consumes only as much space as needed, compatible with ESX 3 or later, supported by VDDK 1.1 or later, and highly recommended.
>>>
VIXDISKLIB_DISK_STREAM_OPTIMIZED – Monolithic sparse format compressed for streaming. Stream optimized format does not support random reads or writes.

Check the sample programs on :

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vddk.pg.doc/vddkSample.7.2.html#995259

 

vSAN Prerequisites and Requirements for Deployment

tapasmahanta124Leave a comment

Before delving into the installation and configuration of vSAN, it’s necessary to discuss the requirements and the prerequisites. VMware vSphere is the foundation of every vSAN based virtual infrastructure.

VMware vSphere:
+++++++++++++++

vSAN was first released with VMware vSphere 5.5 U1. Additional versions of vSAN were released with VMware vSphere 6.0 (vSAN 6.0), VMware vSphere 6.0 U1 (vSAN 6.1), and VMware vSphere 6.0 U2 (vSAN 6.2). Each of these releases included additional vSAN features.

VMware vSphere consists of two major components: the vCenter Server management tool and the ESXi hypervisor. To install and configure vSAN, both vCenter Server and ESXi are required.
VMware vCenter Server provides a centralized management platform for VMware vSphere environments. It is the solution used to provision new virtual machines (VMs), configure hosts, and perform many other operational tasks associated with managing a virtualized infrastructure.
To run a fully supported vSAN environment, the vCenter server 5.5 U1 platform is the minimum requirement, although VMware strongly recommends using the latest version of vSphere where possible. vSAN can be managed by both the Windows version of vCenter server and the vCenter Server appliance (VCSA). vSAN is configured and monitored via the vSphere web client, and this also needs a minimum version of 5.5 U1 for support. vSAN can also be fully configured and managed through the command-line interface (CLI) and the vSphere application programming interface (API) for those wanting to automate some (or all) of the aspects of vSAN configuration, monitoring, or management. Although a single cluster can contain only one vSAN datastore, a vCenter server can manage multiple vSAN and compute clusters.

ESXi:
+++++

VMware ESXi is an enterprise-grade virtualization product that allows you to run multiple instances of an operating system in a fully isolated fashion on a single server. It is a baremetal solution, meaning that it does not require a guest-OS and has an extremely thin footprint. ESXi is the foundation for the large majority of virtualized environments worldwide. For standard datacenter deployments, vSAN requires a minimum of three ESXi hosts (where
each host has local storage and is contributing this storage to the vSAN datastore) to form a supported vSAN cluster. This is to allow the cluster to meet the minimum availability requirements of tolerating at least one host failure.

With vSAN 6.1 (released with vSphere 6.0 U1), VMware introduced the concept of a 2-node vSAN cluster primarily for remote office/branch office deployments. There are some additional considerations around the use of a 2-node vSAN cluster, including the concept of a witness host. As of vSAN 6.0 a maximum of 64 ESXi hosts in a cluster is supported, a significant increase from the 32 hosts that were supported in the initial vSAN release that was part of vSphere
5.5, from here on referred to as vSAN 5.5. The ESXi hosts must be running version 6.0 at a minimum to support 64 hosts however. At a minimum, it is recommended that a host have at least 6 GB of memory. If you configure a host to contain the maximum number of disk groups, we recommend that the host be configured with a minimum of 32 GB of memory. vSAN does not consume all of this memory, but it is required for the maximum configuration. The vSAN host memory requirement is directly related to the number of physical disks in the host and the number of disk groups configured on the host.In all cases we recommend to go with more than 32 GB per host to ensure that your workloads, vSAN and the hypervisor have sufficient resources to ensure an optimal user experience. Below is the Diagram for Minimum host contributing storage :

Cache and Capacity Devices:
+++++++++++++++++++++++++++
With the release of vSAN 6.0, VMware introduced the new all-flash version of vSAN. vSAN was only available as a hybrid configuration with version 5.5. A hybrid configuration is where the cache tier is made up of flash-based devices and the capacity tier is made up of magnetic disks. In the all-flash version, both the cache tier and capacity tier are made up of flash devices. The flash devices of the cache and capacity tier are typically a different grade of flash device in terms of performance and endurance. This allows you, under certain circumstances, to create all-flash configurations at the cost of SAS-based magnetic disk configurations.

 

vSAN Requirements:
++++++++++++++++++
Before enabling vSAN, it is highly recommended that the vSphere administrator validate that the environment meets all the prerequisites and requirements. To enhance resilience, this list also includes recommendations from an infrastructure perspective:
>>Minimum of three ESXi hosts for standard datacenter deployments. Minimum of two ESXi hosts and a witness host for the smallest deployment, for example, remote office/branch office.
>>Minimum of 6 GB memory per host to install ESXi.
>>VMware vCenter Server.
>>At least one device for the capacity tier. One hard disk for hosts contributing storage to vSAN datastore in a hybrid configuration; one flash device for hosts contributing storage to vSAN datastore in an all-flash configuration.
>>At least one flash device for the cache tier for hosts contributing storage to vSAN datastore, whether hybrid or all-flash.
>>One boot device to install ESXi.
>>At least one disk controller. Pass-through/JBOD mode capable disk controller preferred.
>>Dedicated network port for vSAN–VMkernel interface. 10 GbE preferred, but 1 GbE supported for smaller hybrid configurations. With 10 GbE, the adapter does not need to be dedicated to vSAN traffic, but can be shared with other traffic types, such as management traffic, vMotion traffic, etc.
>>L3 multicast is required on the vSAN network.

vSAN Ready Nodes:
++++++++++++++++++
vSAN ready nodes are a great alternative to manually selecting components. Ready nodes would also be the preferred way of building a vSAN configuration. Various vendors have gone through the exercise for you and created configurations that are called vSAN ready nodes. These nodes consist of tested and certified hardware only and, in our opinion,provide an additional guarantee.

For more information please follow : https://www.vsan-essentials.com/

vSAN Performance Capabilities

tapasmahanta124Leave a comment

It is difficult to predict what your performance will be because every workload and every combination of hardware will provide different results. After the initial vSAN launch, VMware announced the results of multiple performance tests
(http://blogs.vmware.com/vsphere/2014/03/supercharge-virtual-san-cluster-2-millioniops.html).

The results Vmwarere impressive, to say the least, but Vmwarere only the beginning. With the 6.1 release, performance of hybrid had doubled and so had the scale, allowing for 8 million IOPS per cluster. The introduction of all-flash hoVmwarever completely changed the game. This alloVmwared vSAN to reach 45k IOPS per diskgroup, and remember you can have 5 per disk group, but it also introduced sub millisecond latency. (Just for completeness sake, theoretically it would be possible to design a vSAN cluster that could deliver over 16 million IOPS with sub millisecond latency using an all-flash configuration.)

Do note that these performance numbers should not be used as a guarantee for what you can achieve in your environment. These are theoretical tests that are not necessarily (and most likely not) representative of the I/O patterns you will see in your own environment (and so results will vary). Nevertheless, it does prove that vSAN is capable of delivering a high performance environment. At the time of writing the latest performance document available is for vSAN 6.0, which can be found here:
http://www.vmware.com/files/pdf/products/vsan/VMware-Virtual-San6-ScalabilityPerformance-Paper.pdf.

Vmware highly recommend hoVmwarever to search for the latest version as Vmware are certain that there will be an updated version with the 6.2 release of vSAN. One thing that stands out though when reading these types of papers is that all performance tests and reference architectures by VMware that are publicly available have been done with 10 GbE networking configurations. For our design scenarios, Vmware will use 10 GbE as the golden standard because it is heavily recommended by VMware and increases throughput and loVmwarers latency. The only configuration where this does not apply is ROBO (remote office/branch office). This 2-node vSAN configuration is typically deployed using 1 GbE since the number of VMs running is typically relatively low (up to 20 in total). Different configuration options for networking, including the use of Network I/O Control.

VSAN 6.6 : New Features

tapasmahanta1241 Comment

VMware vSAN release was just announced, namely vSAN 6.6

There are many new features which were pushed on the latest release ,few of them are listed below:

1: vSAN Encryption : 

Encryption in vSAN 6.6 takes places at the lowest level, meaning that you can also get the benefits of dedupe and compression. vSAN encryption is enabled at the cluster level, but It is implemented at the physical disk layer, so that each disk has its own key provided by a supported Key Management Server (KMS).For customers running all-flash vSAN however there was one big disadvantage and that is that encryption happens at the highest level meaning that the IO is encrypted when it reaches the write buffer and is moved to the capacity tier.

vCenter instance object –> Configure tab –> More / Key Management Servers.

2: Local Protection in vSAN Stretched Cluster : 

There are now two protection policies; Primary level of failures to tolerate (PFTT) and Secondary level of failures to tolerate (SFTT). For stretched cluster, PFTT defines cross site protection, implemented as RAID-1. For stretched cluster, SFTT defines local site protection. SFTT can be implemented as RAID-1, RAID-5 and RAID-6. 

3: Unicast Mode :

If you are upgrading from a previous version of vSAN, vSAN will automatically switch to unicast once all hosts have been upgraded to vSAN 6.6. Now there is a catch to it ,if the on-disk format has not been upgraded to the latest version 5, and a pre-vSAN 6.6 host is added to the cluster, then the cluster reverts to multicast.Here is what you see through the client:

Command you can use is : 

esxcli vsan cluster unicastagent list

4: Resync Throttling :

In the past, if a resync process was interrupted, the resync may need to start all over again. Now in vSAN 6.6, resync activity will resume from where it left off (if interrupted) by using a new resync bitmap to track changes.

5: pre-checks for maintenance mode :

It point out on the data present in the disk group.

Warning message : Data on the disk from the disk group xxxxxxxxx will be deleted . Unless the data on the disks is evacuated first,removing the disks might disrupt working VMs.

Three options but it has all the information in details what we need to understand:

  • Evacuate all data to other host — > It will let you know the amount of data that will be moved to other hosts .
  • Ensure data accessibility from other hosts –>No data will be moved
  • No data evacualtion –> No data will be moved form the location.

6: HTML5 Host Client Integration :

This one is the best and was much awaited feature on VSAN.

For more reference please follow :

 

New esxcli commands for VSAN

tapasmahanta1241 Comment

A new esxcli command to assist with troubleshooting has also been added:

esxcli vsan debug
Usage: esxcli vsan debug {cmd} [cmd options]

Available Namespaces:

 disk Debug commands for vSAN physical disks
 object Debug commands for vSAN objects
 resync Debug commands for vSAN resyncing objects
 controller Debug commands for vSAN disk controllers
 limit Debug commands for vSAN limits
 vmdk Debug commands for vSAN VMDKs

As well as the esxcli vsan debug command, we also added the following commands in vSAN 6.6 information to get troubleshooting information:

 • esxcli vsan health cluster
 • esxcli vsan resync bandwidth
 • esxcli vsan resync throttle
 • esxcli vsan cluster unicastagent list
Example 1:
++++++++++
Use "vsan debug vmdk" command to check all of VMDKs status:
 
 [root@TestVSAN:~] esxcli vsan debug disk list
 UUID: 52bc7654-xxxx-xxxx-xxxx-54cf6cda4368
    Name: naa.xxx
    SSD: True
    Overall Health: green
    Congestion Health:
          State: green
          Congestion Value: 0
          Congestion Area: none
    In Cmmds: true
    In Vsi: true
    Metadata Health: green
    Operational Health: green
    Space Health:
          State: green
          Capacity: 0 bytes
          Used: 0 bytes
          Reserved: 0 bytes
 
Example 2:
++++++++++
 [root@TestVSAN:~] esxcli vsan cluster unicastagent list
NodeUuid IsWitness Supports Unicast IP Address Port Iface Name
------------------------------------ --------- ---------------- ------------- ----- ----------
52e8ac54-xxxx-xxxx-xxxx-54cf6cda4368 0 true 10.10.0.111 12321
52e8ac78-xxxx-xxxx-xxxx-98cf6xas5345 0 true 10.10.0.112 12321
52e8ac21-xxxx-xxxx-xxxx-56ab6cba4368 0 true 10.10.0.113 12321

EVC : How it works

tapasmahanta1241 Comment

EVC is short for Enhanced vMotion Compatibility. EVC allows you to migrate virtual machines between different generations of CPUs.

Because EVC allows you to migrate virtual machines between different generations of CPUs, with EVC you can mix older and newer server generations in the same cluster and be able to migrate virtual machines with vMotion between these hosts. This makes adding new hardware into your existing infrastructure easier and helps extend the value of your existing hosts. With EVC, full cluster upgrades can be achieved with no virtual machine downtime whatsoever. As you add new hosts to the cluster, you can migrate your virtual machines to the new hosts and retire the older hosts.

How to enable EVC in vCenter Server (1013111)

 

How does it work?

After EVC is enabled, all hosts in the cluster are configured to present the CPU features of a user-selected processor type to all virtual machines running in the cluster. This ensures CPU compatibility for vMotion even though the underlying hardware might be different from host to host. Identical CPU features are exposed to virtual machines regardless of which host they are running on, so that the virtual machines can migrate between any hosts in cluster.

ESXi 6.0 supports these EVC modes:

AMD Opteron Generation 1 (Rev. E)
AMD Opteron Generation 2 (Rev. F)
AMD Opteron Generation 3 (Greyhound)
AMD Opteron Generation 3 (no 3Dnow!) (Greyhound)
AMD Opteron Generation 4 (Bulldozer)
AMD Opteron “Piledriver” Generation
Intel “Merom” Generation (Intel Xeon Core 2)
Intel “Penryn” Generation (Intel Xeon 45nm Core2)
Intel “Nehalem” Generation (Intel Xeon Core i7)
Intel “Westmere” Generation (Intel Xeon 32nm Core i7)
Intel “Sandy Bridge” Generation
Intel “Ivy Bridge” Generation
Intel “Haswell” Generation

What happens when a host is removed from an EVC-enabled cluster?

When a host leaves an EVC-enabled cluster, it reverts to its normal behavior. New virtual machines started on that host can access all the features of the CPU, and are not limited by the EVC mode that was in effect while the host was in the EVC cluster. Note that virtual machines that were once able to migrate to the host might no longer be permitted to do so.

Vmware Compatibility Guide looks like this:

 

What is an ill-behaved application, and why does it affect EVC?

An ill-behaved application is one that does not use CPU-vendor-recommended methods of detecting features supported on a CPU. The recommended method is to run the CPUID instruction and look for the correct feature bits for the capabilities the application is expected to use. Unsupported methods used by ill-behaved applications include try-catch-fail or inferring the features present from the CPU version information. When unsupported methods are used, an application might detect features on a host in an EVC cluster that are being masked from the virtual machines. The CPUID-masking MSRs provided by CPU vendors do not disable the actual features. Therefore, an application can still use masked features. If a virtual machine running such an application is then migrated with vMotion to a host that does not physically support those features, the application might fail. VMware is not aware of any commercially-available ill-behaved applications.

For more information, see Detecting and Using CPU Features in Applications (1005763).

This is one of the articles which will explains more on EVC : Enhanced vMotion Compatibility (EVC) processor support (1003212)