As we see a lot of vMotion and Storage vMotion related issues we continue our series about VMware vMotion requirements in this part. If you want to read about the vMotion Technology itself, check out this blog post: 

VMware vMotion, how it works – Part 1 Introduction


Since vMotion is intervening in an active virtual machine without that virtual machine’s knowledge, certain conditions must be fulfilled so that the process can run without problems or failures:

▪       CPU compatibility

▪       vMotion interface (minimum 1 Gb adapter)

▪       shared central mass storage

▪       same naming for virtual port groups

▪       sufficient resources on the target host

▪       at least one vSphere Essentials Plus license on the corresponding ESX host

The only point which can sometimes present significant problems is CPU compatibility. In many firms the server infrastructure developed organically and not every server is built on the same hardware components. It is easy to determine if a virtual machine can be migrated between two ESX servers because in the case of an incompatibility vCenter will issue a warning before the actual migration process begins.

CPU Compatibility

The CPU compatibility problem is easy to explain. Imagine that a virtual machine is started on an ESX host with an AMD CPU and SSE3 functionality. Since VMware ESX is a virtualizer, the guest operating system sees all of the standard CPU functionality and can be adapted to the hardware with extra drivers to more effectively utilize multimedia functions. 

If this virtual machine is simply transferred to another host with a CPU that only supports SSE2, the guest operating system will still want to use the SSE3 functionality. This can cause problems or even a system crash. While these problems can sometimes be managed by so-called “CPU masking”, very large differences between CPUs remain unresolvable. Examples of large differences include switching from an AMD to an Intel CPU, or from a 64-bit to a 32-bit CPU.

Since the ESX server cannot predict which CPU instructions the virtual machine (or rather the guest operating system) will use, the user must pay attention to either use identical CPUs or to configure a proper masking.

The VMware’s CPU Identification Utility allows the user to determine which functionality the installed CPU has, including vMotion compatibility, EVC, and 64-bit support. This tool can be found at _http://www.vmware.com/support/shared_utilities_.

The VMware Knowledge Base articles 1991 (Intel) and 1992 (AMD) explain which CPUs are compatible with which others:

▪       Intel: http://kb.vmware.com/kb/1991

▪       AMD: http://kb.vmware.com/kb/1992

The upgrade from VI3.x to vSphere unfortunately introduces a very serious issue regarding CPU masking, which was often set automatically in VI3.x in the configuration of the virtual machine. After the upgrade certain virtual machines no longer support migration via vMotion and return an error message. 

This problem has not yet been reported when upgrading from vSphere 4 to vSphere 5.x. The solution is very simple: CPU masking must be set to default by choosing Reset all values to default in the CPU identification mask settings of the virtual machine. The only irritating thing is that the VM must be shut down in order for these settings to go into effect. The corresponding Knowledge Base article can be accessed at http://kb.vmware.com/kb/1011294.

CPU Masking and EVC

In the settings for a virtual machine the option CPU-ID -Mask can be activated to hide disabled VM CPU functionality. By hiding certain CPU features, vMotion compatibility between ESX hosts with different CPU generations can be improved . 

VMware vMotion requirements - CPU advanced settings

You can configure CPU masking in the settings of the virtual machine.

The standard option is the hiding of non-execution bits, which is only supported by newer CPUs (NX/XD flag). If this is activated a virtual machine can be migrated between ESX servers where it doesn’t matter if the processors provide NX functionality or not, unless there are other CPU instructions which are different and cannot be hidden. 

If the non-execution bit is not sufficient it is also possible to configure CPU-manufacturer-specific settings. This means it is possible to adjust the registers in general or for Intel and AMD processors specifically. For example if you are using an AMD processor and want to hide the SSE3 functionality, the option looks as follows:

Level 1 – row ecx : —- —- —- —- —- —- —0 -0-0

A very good VMware Knowledge Base article about the different masks and corresponding processors can be found here:


If you want to revert your changes to a specific entry this is done by clicking revert to default values when the row is selected. Or you can set all values to default by selecting revert all values to default values.

Convenience or Speed

When regulating CPU mask settings you should keep in mind that hiding certain functionality can slow down the guest operating system. Effectively you must decide between convenience and speed, depending on the guest operating system.

EVC (Enhanced vMotion Compatibility)

For users that don’t want to define the CPU masking for every virtual machine, EVC-cluster is capable of adjusting CPU functionality globally. This means that a user can define in the cluster options which CPU generations can be seen from the virtual machines within the cluster. This can be configured with the least common denominator of all host CPUs in the cluster.

_Cluster EVC settings - VMware vMotion requirements_

In the cluster settings the CPU generation can be set globally for the entire cluster.

Since vSphere, EVC has supported the incrementation of processor generation during the operation of the virtual machine, for example from CPU generation 1 to 2. However a downgrade of CPU generation is not possible with this method. If the CPU generation is increased, active virtual machines will receive the new settings at the next power down or reset.

Within the EVC cluster, the EVC function guarantees that no CPU incompatibilities due to differing CPU generations will result from vMotion procedures. This does not suppress, however, other factors that may hinder the use of vMotion, for example the use of local hard disks.

VMware vMotion requirements

Making sure you meet all VMware vMotion requirements should be you highest priorization.

Btw. if you want to get a good feeling about your daily vMotion tasks and how long they take, check out our 

VMotion/svMotion Report

Metrics and Logs

(formerly, Opvizor Performance Analyzer)

VMware vSphere & Cloud

Monitor and Analyze Performance and Log files:
Performance monitoring for your systems and applications with log analysis (tamperproof using immudb) and license compliance (RedHat, Oracle, SAP and more) in one virtual appliance!

Subscribe to Our Newsletter

Get the latest product updates, company news, and special offers delivered right to your inbox.

Subscribe to our newsletter

Use Case - Tamper-resistant Clinical Trials


Blockchain PoCs were unsuccessful due to complexity and lack of developers.

Still the goal of data immutability as well as client verification is a crucial. Furthermore, the system needs to be easy to use and operate (allowing backup, maintenance windows aso.).


immudb is running in different datacenters across the globe. All clinical trial information is stored in immudb either as transactions or the pdf documents as a whole.

Having that single source of truth with versioned, timestamped, and cryptographically verifiable records, enables a whole new way of transparency and trust.

Use Case - Finance


Store the source data, the decision and the rule base for financial support from governments timestamped, verifiable.

A very important functionality is the ability to compare the historic decision (based on the past rulebase) with the rulebase at a different date. Fully cryptographic verifiable Time Travel queries are required to be able to achieve that comparison.


While the source data, rulebase and the documented decision are stored in verifiable Blobs in immudb, the transaction is stored using the relational layer of immudb.

That allows the use of immudb’s time travel capabilities to retrieve verified historic data and recalculate with the most recent rulebase.

Use Case - eCommerce and NFT marketplace


No matter if it’s an eCommerce platform or NFT marketplace, the goals are similar:

  • High amount of transactions (potentially millions a second)
  • Ability to read and write multiple records within one transaction
  • prevent overwrite or updates on transactions
  • comply with regulations (PCI, GDPR, …)


immudb is typically scaled out using Hyperscaler (i. e. AWS, Google Cloud, Microsoft Azure) distributed across the Globe. Auditors are also distributed to track the verification proof over time. Additionally, the shop or marketplace applications store immudb cryptographic state information. That high level of integrity and tamper-evidence while maintaining a very high transaction speed is key for companies to chose immudb.

Use Case - IoT Sensor Data


IoT sensor data received by devices collecting environment data needs to be stored locally in a cryptographically verifiable manner until the data is transferred to a central datacenter. The data integrity needs to be verifiable at any given point in time and while in transit.


immudb runs embedded on the IoT device itself and is consistently audited by external probes. The data transfer to audit is minimal and works even with minimum bandwidth and unreliable connections.

Whenever the IoT devices are connected to a high bandwidth, the data transfer happens to a data center (large immudb deployment) and the source and destination date integrity is fully verified.

Use Case - DevOps Evidence


CI/CD and application build logs need to be stored auditable and tamper-evident.
A very high Performance is required as the system should not slow down any build process.
Scalability is key as billions of artifacts are expected within the next years.
Next to a possibility of integrity validation, data needs to be retrievable by pipeline job id or digital asset checksum.


As part of the CI/CD audit functionality, data is stored within immudb using the Key/Value functionality. Key is either the CI/CD job id (i. e. Jenkins or GitLab) or the checksum of the resulting build or container image.

White Paper — Registration

We will also send you the research paper
via email.

CodeNotary — Webinar

White Paper — Registration

Please let us know where we can send the whitepaper on CodeNotary Trusted Software Supply Chain. 

Become a partner

Start Your Trial

Please enter contact information to receive an email with the virtual appliance download instructions.

Start Free Trial

Please enter contact information to receive an email with the free trial details.