VMware

EVC and CPU Compatibility FAQ

Posted on


What is EVC?

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

What is the benefit of EVC?

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 do I use EVC?

EVC is enabled for a cluster in the VirtualCenter or vCenter Server inventory. After it is enabled, EVC ensures that migration with vMotion is possible between any hosts in the cluster. Only hosts that preserve this property can be added to the cluster.

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.

Can migrations with vMotion still fail for virtual machines within an EVC cluster?

Yes. More factors than CPU compatibility are used to determine vMotion compatibility. For example, if the virtual machine does not reside on storage shared by the source and destination hosts, then migration with vMotion cannot occur between these hosts.

Does EVC allow AMD and Intel CPUs to be vMotion compatible?

No. An EVC-enabled cluster only allows CPUs from a single vendor in the cluster. VirtualCenter and vCenter Server do not allow you to add a host from a different CPU vendor into an EVC-enabled cluster.

What EVC modes are available?

ESXi/ESX 3.5 Update 2 and later supports two EVC modes:

  • AMD Opteron Generation 1 (Rev. E)
  • Intel “Merom” Generation (Intel Xeon Core 2)

In the earlier ESXi/ESX 3.5 releases, these modes were labeled simply AMD and Intel. Later updates use the names listed above.

ESXi/ESX 4.0 supports these EVC modes:

  • AMD Opteron Generation 1 (Rev. E)
  • AMD Opteron Generation 2 (Rev. F)
  • AMD Opteron Generation 3 (Greyhound)
  • Intel “Merom” Generation (Intel Xeon Core 2)
  • Intel “Penryn” Generation (Intel Xeon 45nm Core2)
  • Intel “Nehalem” Generation (Intel Xeon Core i7)

ESXi/ESX 4.0 Update 1 and later supports these EVC modes:

  • AMD Opteron Generation 1 (Rev. E)
  • AMD Opteron Generation 2 (Rev. F)
  • AMD Opteron Generation 3 (Greyhound)
  • 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)

ESXi/ESX 4.1 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)
  • 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)

ESXi 5.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)
  • 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

ESXi 5.1 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
ESXi 5.5 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

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

Which CPUs are compatible with each EVC mode?

To determine the EVC modes compatible with your CPU, search the VMware Compatibility Guide. Search for the server model or CPU family, and click the entry in the CPU Series column to display the compatible EVC modes.

What are the differences between the modes?

Each mode corresponds very closely to the features available in processors with the same name. Newer processors and their corresponding modes include additional features such as new instructions. For example, the Intel Xeon Core i7 processor added the SSE4.2 instruction set. These instructions are not available in earlier processors or their corresponding EVC modes.

AMD EVC modes expose these features:

EVC Mode
Available Features
AMD Opteron Generation 1 All features of AMD Opteron Rev. E CPUs
AMD Opteron Generation 2 All features of AMD Opteron Generation and additional CPU features including CMPXCHG16B and RDTSCP
AMD Opteron Generation 3 All features of AMD Opteron Generation 2 and additional CPU features including SSE4A, MisAlignSSE, POPCOUNT, ABM (LZCNT)
AMD Opteron Generation 3 (no 3Dnow!) Applies baseline feature set of AMD Opteron Generation 3 (Greyhound) processors, with 3DNow! support removed, to all hosts in the cluster.

This mode allows you to prepare clusters containing AMD hosts to accept AMD processors without 3DNow! support.

AMD Opteron Generation 4 Applies baseline feature set of AMD Opteron Generation 4 (Bulldozer) processors to all hosts in the cluster.

This EVC mode exposes additional CPU features including SSSE3, SSE4.1, AES, PCLMULQDQ, XSAVE, AVX, XOP and FMA4.

AMD Opteron “Piledriver” Generation Applies baseline feature set of AMD Opteron “Piledriver” Generation processors to all hosts in the cluster.

This EVC mode exposes additional CPU features including FMA3 (three operand FMA, aka Intel’s FMA), BMI1 and TBM.

 

Intel EVC modes expose these features:

EVC Mode Available Features
Intel “Merom” Generation (Intel Xeon Core2) All features of Intel Core2 CPUs
Intel “Penryn” Generation (Intel Xeon 45nm Core2) All features of Intel Core2 CPUs and additional CPU features including SSE4.1
Intel “Nehalem” Generation (Intel Xeon Core i7) All features of Intel Core2 CPUs and additional CPU features including SSE4.2 and POPCOUNT
Intel “Westmere” Generation (Intel Xeon 32nm Core i7) Applies baseline feature set of Intel Xeon 32nm Corei7 (Westmere) processors to all hosts in the cluster. Compared to the Intel Xeon Corei7 mode, this EVC mode exposes additional CPU features including AES and PCLMULQDQ.

Note: Intel i3/i5 Xeon Clarkdale Series processors that do not support AESNI and PCLMULQDQ cannot be admitted to EVC modes higher than the Intel Xeon Corei7 mode.
Note: Intel® Atom™ C2300-C2700 processors support the Intel® “Westmere” Gen. EVC baseline although their architecture is different from the architecture of the Intel® “Westmere” Generation processors.

Intel “Sandy Bridge” Generation Applies baseline feature set of Intel “Sandy Bridge” Generation processors to all hosts in the cluster.

This EVC mode exposes additional CPU features including AVX, XSAVE and ULE.

Note: Some Sandy Bridge microarchitecture processors do not provide the full Sandy Bridge feature set. Such processors do not support EVC mode; they will only be admitted to the Intel Nehalem Generation mode or below.

Intel “Ivy Bridge” Generation Applies baseline feature set of Intel “Ivy Bridge” Generation processors to all hosts in the cluster.

This EVC mode exposes additional CPU features including ENFSTRING, F16C, FSGSBASE, SMEP and CPUID Faulting.

Intel “Haswell” Generation
Applies the baseline feature set of Intel “Haswell” Generation processors to all hosts in the cluster.

This EVC mode exposes additional CPU features including Advanced Vector Extensions 2, fused multiply-adds, Transactional Synchronization Extensions, and new bit manipulation instructions.

How can I find the EVC mode supported by a host?

In the vSphere Client connected to vCenter Server 4.0, the host Summary tab indicates whether EVC is enabled, and displays the current EVC mode for the host. Click the blue icon next to the EVC mode to display a list of all the supported EVC modes for the host.

VMware also provides a free CPU identification utility that displays compatible EVC modes, in addition to other CPU features. You can download this utility and boot the host from the ISO image.

If I have an EVC-enabled cluster set to a particular EVC mode, and I have a host outside the cluster that matches the EVC mode, can I migrate a virtual machine with vMotion between that host and the cluster?

Yes, in both directions.

How do I handle Intel Xeon E3 and E5 Processors or Intel Xeon X-series, E-series, L-series Processors that have different revision or series numbers (e.g. v2, v3, v4 or x5680, x5687, x5690)

When enabling EVC for a cluster with Intel processors of the Xeon E3 or Xeon E5 family that have different revision numbers (v2, v3, v4), an EVC baseline is required. This is due to new instruction sets being available in the different revisions.  Although the processors will be the same EVC baseline, this is required for the processors to all present the same instruction sets to the virtual machines.

As with Xeon process with different revisions, when enabling EVC for a cluster with Intel processors of the same Xeon family (e.g. E56xx, X56xx, L56xx), an EVC baseline is required. This is due to new instruction sets being available in the different revisions.  Although the processors will be the same EVC baseline, this is required for the processors to all present the same instruction sets to the virtual machines.

What is the difference between EVC and the old CPUID masking feature (accessed from the Virtual Machine Settings dialog box, Options tab, CPUID mask option)?

The older masking feature involved applying manual masks to individual virtual machines. EVC takes effect on a whole cluster and all virtual machines in the cluster. More accurately, EVC affects the hosts themselves, making all the hosts in the cluster appear to be the same type of CPU hardware, even if they are different.

Why is the . vmx config file for the virtual machine updated with CPUID bits?

The .vmx file contains information about the features that the virtual machine is using. VirtualCenter and vCenter Server need this information to provide accurate vMotion compatibility checks. These values are unrelated to the old CPUID mask values that also appear in the .vmx file.

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.

If I raise the EVC mode, will virtual machines be able to access the new features available in that mode?

Not until you power off and then power on the virtual machines. A reboot of the guest operating system is not sufficient. A virtual machine determines which features are available to it at power on, and cannot access any new features that are added until it is powered off.

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).

Can I create an EVC-enabled cluster if some of the hosts I want to add do not have AMD-V Extended Migration or Intel VT FlexMigration?

Yes. EVC-enabled clusters can contain hosts that do not feature AMD-V Extended Migration or Intel VT FlexMigration technology. For example, Intel Xeon Core2 processors do not have Intel VT FlexMigration technology, but can be added to clusters configured with an Intel Xeon Core2 EVC mode.

Can I add an ESXi/ESX 3.5 Update 1 or earlier host to an EVC-enabled cluster?

No. EVC is supported only on ESXi/ESX 3.5 Update 2 and later. vCenter Server does not permit the addition of hosts that do not provide support for EVC into an EVC-enabled cluster.

If I add newer hardware into an EVC-enabled cluster with a lower EVC mode, do I lose performance?

All CPU features provided by your host hardware are available to the hypervisor. Optimizations for CPU virtualization such as AMD-V and Intel VT-x or facilities for MMU virtualization such as AMD RVI or Intel EPT support are still used by the hypervisor. Only those CPU instructions that are unique to the new CPU are hidden from virtual machines when the host joins the EVC-enabled cluster. Typically this includes new SIMD instructions, such as the latest SSE additions. It is possible, but unlikely, that an application running in a virtual machine would benefit from these features, and that the application performance would be lower as the result of using an EVC mode that does not include the features. Check with the application vendor to determine which CPU features are used by the application.

How do I know when I can raise the EVC mode for a cluster?

You can raise the EVC mode for an EVC-enabled cluster if all hosts in the EVC cluster support the higher mode. This may occur periodically over time as older hosts are retired from the cluster and newer hosts are added. Use the Change EVC Mode dialog box to determine the EVC modes currently available to your cluster.
Can I enable EVC on an existing non-EVC enabled cluster with powered-on virtual machine guests?
For information related to vCenter Server 5.0, see CPU Compatibility and EVC in the vCenter Server and Host Management Guide.
For information related to vCenter Server 4.1, see CPU Compatibility and EVC in the vSphere Datacenter Administration Guide.

What is the impact on vSphere Cluster Features when I disable the EVC mode?

When disabling EVC mode on a cluster, it affects vSphere Cluster Features in the following ways:
  • vSphere HA (High Availability): vSphere HA is not impacted due to the failover power-cycling the virtual machines when starting them on a a new host. This allows the virtual machine to pick up the new CPU ID and allows it to start without a problem
  • vSphere DRS (Distributed Resource Scheduler):
    • vMotion:
      • Prior to power cycling the virtual machines:
        • They will maintain CPU level until a power cycle occurs.
        • DRS and vMotion operations will be the same as prior to disabling EVC mode.
      • Once the virtual machine is power cycled:
        • They are only able to move to other ESX/ESXi hosts that are at the same CPU generation or newer.
        • They will take on the CPU settings from the ESXi host it is running on.  This can prevent DRS operations and vMotioning of the virtual machine to another host due to CPU incompatibility.
    • Storage vMotion: Virtual machines are able to be moved to Storage vMotion with EVC mode disabled within a cluster
  • Swapfile Location: This is not impacted.
Advertisements

VMware View 4.0 Installation and Configuration

Posted on Updated on


VMware View 4 allows you to consolidate virtual desktops on datacenter servers and manage operating systems with improved reliability, better managementOverview

Features

  • Print from a virtual desktop to any local or networked printer that is defined on the client device.
  • Use multiple monitors With VMware PCoIP multiple-monitor support.
  • Access USB devices and other peripherals that are connected to the local device that displays your virtual desktop.
  • Use Microsoft Active Directory to manage access to virtual desktops and to manage policies.
  • Use the Web-based administrative console to manage virtual desktops from any location.
  • Use a template, or master image, to quickly create and provision pools of desktops.
  • Send updates and patches to virtual desktops without affecting user settings, data, or preferences.

Components of VMware View Enterprise:

  • View Connection Server 4 (Install on dedicated server)
  • View Agent (Install on virtual desktop VM)
  • View Client (Install on client physical desktop

Components of VMware View Premier:

  • View Connection Server 4 (Install on dedicated server)
  • View Composer 2 (Install on vCenter server)
  • View Agent (Install on virtual desktop VM)
  • View Client (Install on client physical desktop)
  • View Client Offline Desktop (Install on client physical laptop)

Pre-requisites:

Components Requirements
View Connection Server 4.0 ·  32bit or 64bit server

·  Pentium IV 2.0GHz processor or higher

·  2GB RAM or higher

·  One or more 10/100Mbps network interface cards (NIC)

·  Windows Server 2003 Standard or Enterprise with Service Pack 2

·  Valid View 4.0 license keys

·  Administrator rights on the domain user account used to install View Connection Server 4.0

·  VMware Infrastructure 3.0.2, VMware Infrastructure 3.5 Updates 3 or 4 or vSphere 4 Update 1

·  RSA Authentication Manager

·  Windows 2000, 2003 or 2008 Active Directory

View Composer 2.0 ·  Windows Server 2003 Standard or Enterprise with Service Pack 1 or Windows XP Professional with Service Pack 2

·  A supported SQL database.

View Administrator ·  Internet Explorer 7, Internet Explorer 8, Firefox 3.0 or Firefox 3.5

Installation Overview

The complete setup of Vmware View 4.0 environment includes 3 steps:

  • Installing VMware View Connection Server 4
  • Installing VMware View Composer 2
  • Configuring VMware View Connection Server 4 with View Manager

Installing VMware View Connection Server 4

Note:

  • The View Connection Server must be installed on its own dedicated server. It cannot be installed on the vCenter server.
  • It acts as a broker for client connections by authenticating directing incoming remote desktop user requests to a virtual desktop, physical desktop, or terminal server.
  1. Double Click “VMware-viewconnectionserver-4.xxxxx.exe” to start the installer.
  2. The installation wizard is displayed. Click Next.
  3. Read and Accept the VMware license agreement, Click Next.
  4. Enter the destination folder to install VMware View Composer. Click Next.
  5. Select “Standard” for the server instance type (as this is the first server). Click Next.
  6. Read and Accept the Microsoft ADAM license agreement, Click Next.
  7. Click Install to start the installation of the View Connection Server.
  8. Once the installation has completed Click Finish.

Installing VMware View Composer 2

Note:

  • VMware View Composer 2 is a component of View 4 Premier Edition.
  • Composer must be installed on the vCenter Server.
  1. Double Click “VMware-viewcomposer-2.0.0-210930.exe” to start the installer.
  1. You may receive a message about updating Microsoft .NET depending on which version you have installed. Click Ok to update .NET.
  1. After updating .NET (if it was required) the installation wizard is displayed. Click Next.
  1. Read and Accept the license agreement, Click Next.
  1. Enter the destination folder to install VMware View Composer. Click Next.
  1. VMware View Composer requires a MS SQL database. Enter the required details and Click Next.
  1. Confirm the SOAP port to use and note the SSL certificate being created. Click Next.
  1. Click Install to start the installation of Composer.
  1. Once the installation has completed Click Finish.
  1. It is required to restart the server to complete the installation. Click Yes to Restart.

Configuring VMware View Connection Server 4 with View Manager

  • View Manager 4 is a core component of VMware View 4 that is installed on the View Connection Server.
  • View Manager is a single console used to manage and deploy virtual desktops

Follow the below steps to configure the Vmware View Connection Sevrer

  1. Login to View Manager Administrator
  1. License the server.
  • Navigate to the “Configuration” tab and the “Product Licensing and Usage” section.
  • Click “Edit License” and enter the license.
  1. Add the vCenter Server.
  • Navigate to the “Configuration” tab and the “Servers” section.
  • Click “Add” to add the vCenter server.
  1. Enter the vCenter server details:
  • Server Address (FQDN)
  • Username
  • Password
  1. Optionally (If Premier Edition) enter View Composer Server details:
  • Click “Add” to add a Quick Prep domain.
  • Click Ok to save all the settings.
  1. Confirm the vCenter Server details are added correctly.
  2. Confirm the View Connection Server is activated.
  • Navigate to the “Configuration” tab and the “Registered Desktop Sources” section.
  1. Configure Connection Server Settings.
  • Select a Connection Server and Click “Edit”.
  • By default these settings do not need to be changed for View to work. However here you will find settings for smart cards, 2-factor authenication and backup of the View Manager Configuration.
  1. Configure any additional Administrators of VMware View Manager.
  • Navigate to the “Configuration” tab and the “Administrators” section.
  • Click “Add” to add any additionally groups that require administrator permissions in View Manager.
  • By default this is only BUILTIN\Administrators group on the connection server.
  1. Configure any require global settings.
  • Navigate to the “Configuration” tab and the “Global Settings” section.
  • Under the global settings configure any additional settings for session timeouts, login messages and forced logoff messages.
  • Click Ok to save the settings.

Zerto vs vSphere Replication

Posted on Updated on


Zerto vs vSphere Replication (focusing around data replication)

Zerto Replication vSphere Replication
Generally recommended for: Any size vSphere infrastructure Small infrastructures, remote offices, and non-critical applications
Max number of VMs protected per appliance and vCenter Server: 500/5000 500/500
Linked clone and template support: Yes No
Physical RDM and Virtual RDM support: Yes, virtual and physical mode RDMs are supported No/Yes, Physical RDMs are not supported but virtual RDM are supported
RPO range: Seconds 15 minutes to 24 hours
Application consistent?: Supports Windows VMs using VSS and Linux with Application Quesicense Only with Windows VMs using VSS
How VMs are chosen: VMs can be organized into Virtual Protection Groups VMs can be selected individually or multi-select but virtual protection grouping is not available
Automated failback support: Yes No, VMware recommends SRM
Allows you to plan, test, and automate failover and failback: Yes No, VMware recommends SRM
Compression included: Yes No, and neither does SRM
RE-IP addressing of virtual machines: Yes No, VMware recommends SRM
Cloning of recovery sites: Yes No
Point in time recovery: Yes, up to 5 days with standard recovery, up to 1 year with extended recovery using the Offsite Backup feature Yes, up to 24 snapshots
Compatible with vApps: Yes No
vCloud Director integration: Yes No
Snapshot-based? No Yes/No, VMware says that vSR doesn’t use snapshots technology but does use a modified version of CBT, still many of the same snapshot-based limitations apply. For example, vSR uses VM snapshots at the recovery site when recovering to a different point-in-time.

Zerto vs VMware Site Recovery Manager (focusing around automation of disaster recovery planning, testing, and automation)

Zerto SRM (with vSphere Replication)
Provides planning, testing, and execution of disaster recovery for vSphere: Yes Yes
Designed for: Zerto was designed for hypervisor-based replication AND disaster recovery orchestration SRM was designed for disaster recovery orchestration only
Licensed: Per-VM Per-VM
Replication granularity: Per-VM and/or Per- Virtual Protection Group Per-VM or multi-select but virtual protection grouping is not available
Configure consistency groups (virtual protection groups): Yes No
Replication recovery points: Yes, up to 5 days with standard recovery, up to 1 year with extended recovery using the Offsite Backup feature Yes, up to 24 snapshots
Compatibility: Zerto works with ESX 4.0 U1 and above. Zerto can replicate between different versions of vCenter. vSR works with ESX 5.x and above. SRM requires the same version of vCenter and SRM be installed at both sites.
Managed with: vSphere Client Plugin and stand-alone browser UI vSphere Client Plugin
Replication is performed with: Zerto Hypervisor-based replication vSphere Replication

Command to get the ESXi host information from a running VM

Posted on Updated on


Not able to find the VM in the vCenter/inventory? here is a way, there is a Command to get the ESXi host information from a running VM.

To get ESXi host name:

C:\>”C:\Program Files\VMware\Vmware Tools\vmtoolsd.exe” –cmd “info-get guestinfo.hypervisor.hostname”

To get the ESXi Build details:

C:\>”C:\Program Files\VMware\Vmware Tools\vmtoolsd.exe” –cmd “info-get guestinfo.hypervisor.build”

How to cancel a hang task in vCenter or ESXi host?

Posted on Updated on


Sometime we may need to cancel an hung task like active vmotion/backup which may show as disabled from the vSphere client.

  1. First check if there is an active task running for the VM in the Task and Events Tab.
  2. Log in to ESXi host via SSH (using e.g. putty). If the SSH service is not running on ESXi host, please enable it.
  3. Run ps command. use grep e.g. ps | grep VM_name
  4. Kill the parent process by running the command kill id_parent e.g. kill 859467
  5. The hang task should be canceled now and will reflect in the Tasks and Events in the vCenter.

 

A QUICK REFERENCE OF VSPHERE IDS

Posted on Updated on


Here is a list of a number of the different IDs used in the virtual infrastructure and how they are used:

  1. VC Instance UUID(aka serverGuid): This is a GUID that identifies the vCenter server.  This is accessible from the AboutInfo property in the VIM API.  The property name is AboutInfo#instanceUuid.  It’s set at install time and is persisted so the value is durable for a given VC instance.

To access this via PowerCLI you can use the following:

1

2

3

 

PS C:\> $vcenter = Connect-viserver vcsa-01a.corp.local -User Administrator@vsphere.local -Password VMware1!

PS C:\> $vcenter.InstanceUuid

d322b019-58d4-4d6f-9f8b-d28695a716c0

 

  1. The ESX Host UUIDis read by the ESX host from the System Management BIOS (SMBIOS). This UUID is not generated by VMware, it is unique to the hardware and is set in the BIOS by the vendor.

To access this via PowerCLI you can use the following:

1 (Get-VMHost | Select -first 1).ExtensionData.hardware.systeminfo.uuid

 

  1. VC-VM Instance UUID: This is the vc.uuid property in the VM vmx configuration file and also the instanceUuid property on the VmConfigInfo for a VirtualMachine in the VIM API.  This UUID is used by vCenter to uniquely identify VMs that it is managed.  vCenter assigns this UUID to the VM after it is created.  There are different workflows where a VM may not have a UUID initially or may have a duplicate.  vCenter actively looks over the VM inventory and will automatically patch the VM instance UUID if it sees a duplicate.

The scope of this uniqueness scan is a vCenter instance.  If there are duplicate VC-VM Instance UUIDs, they will not be detected as duplicates unless the VMs are managed by the same vCenter instance.  This value can be changed through the API.

To access this via PowerCLI you can use the following:

1

2

3

PS C:\> (Get-VM | Select -first 1).extensiondata.config.InstanceUUID

502e363d-393c-b0a4-8ede-639db30a625e

 

  1. VM SMBIOS UUID: This is the uuid.bios property in the VM vmx configuration file.  In the VIM API, this is the uuid property on the VmConfigInfo for a VirtualMachine managed object.  This UUID is visible to the guest OS as the SMBIOS UUID.  VMware generally try to avoid changing this UUID since it is often used by applications that manage the guest OS instances.  When the VM is migrated this UUID is maintained.

vCenter does a best effort to try to make sure these UUIDs are unique in an environment.  For operations like clone and deploy that create a new VM, a new UUID is provided to the VM by clearing the uuid.bios from the VM’s vmx file.  If the VM is copied without vCenter’s knowledge, 3rd party tools are advised to do the same thing as vCenter.  A new uuid.bios is generated the next time the VM is powered on.  This UUID is generated by the ESXi server so vCenter does not have to be in the control flow for the uuid.bios to be generated.

To access this via PowerCLI you can use the following:

1

2

3

PS C:\> (Get-VM | Select -first 1).extensiondata.Config.UUID422ee9f4-6cfd-1fb7-1376-a8ecb8eb8568
  1. VM Location ID: This identifier is stored in the VM configuration file as the variable uuid.location.  In the VIM API, the name is locationId also on the VmConfigInfo of the VirtualMachine.  This is one other detail that might be relevant to a 3rd party solution that might be moving the VM without vCenter’s knowledge.  This property is used in conjunction with the VM SMBIOS UUID.  This property is a hash of the VM’s configuration file and some UUID of the ESXi. The purpose of this UUID is to detect out-of-band migrations and copies of the VM.  If vSphere (or Workstation/Fusion) detect that the locationId is no longer valid, it will pop up dialog/question/error asking the user why the locationId is no longer valid.  The user is prompted to answer whether the VM was moved or copied.  The purpose is so that vSphere can determine whether it should keep the existing the SMBIOS UUID or generate a new one.

Recall, I mentioned that vCenter is doing a best effort to ensure the SMBIOS UUID is unique.  But when it detects a potential conflict, vCenter will not automatically patch the UUID since this could break 3rd party and VMware products that rely on the guest visible UUID to correlate the VM with other management entities in the environment.

The way 3rd party solutions can best interoperate with vCenter and it’s attempt to preserve a unique SMBIOS UUID is to be aware of these semantics.  If a 3rd party solution or program is moving the VM, it should clear out the uuid.location (ie. ConfigInfo.locationId) property.  On next power on, a new uuid.location will be generated, binding the VM to ESXi host and the file path where it is running.

Despite this however, there is a theoretical and real possibility that there could be duplicate SMBIOS UUIDs.  Because vCenter is deferring to what the user of the system what the the SMBIOS UUID should be, it will not change the UUID automatically if it detects conflicts.  If there SMBIOS UUIDs that are duplicated, it will not fix them.

To access this via PowerCLI you can use the following:

1

2

3

PS C:\> (Get-VM | Select -first 1).extensiondata.config.LocationId

 

564d043c-5dab-5413-c4a7-fb0837d354d9

  1. VM MoRef: The VM MoRef is a short key used by a vCenter instance to identify the VM.  This is the primary identifier used by the VIM API to refer to the VM.  The other identifiers can generally be used to find the VM, but the VM MoRef is the one that must ultimately be used to get data and issue operations to modify the VM.

In general, the MoRef is the important identifier because that’s what is used in the VC database to associate a VM to its stats, events, and configuration.

In environments where multiple vCenters are used, the MoRef will not necessarily be unique.  As a result, another identifier needs to paired with the VM MoRef or used instead.  In general, vSphere uses a combination of the vCenter instance UUID (ie. the serverGuid) with the MoRef to identify the VM for cross-vCenter scenarios like Linked Mode.

To access this via PowerCLI you can use the following:

1

2

PS C:\> (Get-VM | Select -first 1).ExtensionData.Moref.Value

vm-43

 

How to fix corrupt image profile issues on an ESXi host?

Posted on Updated on


Recently I happen to deal with such an issue while installing the patches on an ESXi host using vSphere Update Manager. This issue is rare and will occur if you interrupt the patches remediation task abruptly, in my case thanks to one of my colleague.

I will mention the steps which helped me to recover the image profile for the ESXi host.

Issue: No image profile is found on the host or image profile is empty. In my case image profile shows Unknown – no profile defined

image profile issue

Resolution:

This issue has been seen on systems where the image database file, imgdb.tgz, is corrupt. An image profile is required to install or remove VIBs.

How to confirm if you are proceed with the mentioned solution:

To confirm that the imgdb.tgz file is corrupt:

Connect to the ESXi host via an SSH session.

Change directory to /vmfs/volumes by cd /vmfs/volumes

Search for the imgdb.tgz file: find * | grep imgdb.tgz

 

Note: This command normally results in two matches. For example:

0ca01e7f-cc1ea1af-bda0-1fe646c5ceea/imgdb.tgz

edbf587b-da2add08-3185-3113649d5262/imgdb.tgz

 

Run this command on each match:

ls -l match_result

For example:

ls -l 0ca01e7f-cc1ea1af-bda0-1fe646c5ceea/imgdb.tgz

-rwx——   1 root root  26393 Jul 20 19:28 0ca01e7f-cc1ea1af-bda0-1fe646c5ceea/imgdb.tgz

 

The default size for the imgdb.tgz file is approximately 26 KB. If one of the files is only a couple of bytes, it indicates that the file is corrupt.

 

There are 2 ways you can fix this issue. To work around this issue, perform one of these options:

1. Rebuild the ESXi host

OR

2. Copy an imgdb.tgz file from a known good ESXi host to the host having the issue

 

You may rebuilt if you want but that is not what you are looking for!

Now let us see how we can proceed with the second option:

 

To copy the imgdb.tgz file from a known good ESXi host perform the following:

On the working ESXi host, copy a good copy of imgdb.tgz by perform the following

cp /bootbank/imgdb.tgz /vmfs/volumes/<shared-LUN>

On the corrupt host, copy the good copy of the imgdb.tgz to /tmp:

cp /vmfs/volumes/<shared LUN>/imgdb.tgz /tmp

cd /tmp

tar -xzf imgdb.tgz

Copy the good profile files to the profile directory:

cp /tmp/var/db/esximg/profiles/* /var/db/esximg/profiles/

Copy the good VIBs to the VIB repository:

cp /tmp/var/db/esximg/vibs/* /var/db/esximg/vibs/

Remove the corrupt imgdb.tgz from the bootbank:

rm /bootbank/imgdb.tgz

Move the good copy of imgdb.tgz into the bootbank:

cp /tmp/imgdb.tgz /bootbank/

Backup configuration changes made:

/sbin/auto-backup.sh

Restart the ESXi host, Attempt to install or patch the host again using vSphere Update Manager.