vmware-vmotion-operations-part-4

Operating vMotion is very intuitive and trivial, since an active virtual machine can be moved to another ESX host just by drag and drop. Since the virtual machine is active, the vMotion process starts automatically with the first dialog.

start vMotion Migration of VM

Figure 1: Starting a migration process from the context menu of the virtual machine

Another variation is performed by choosing migrate from the context menu of a virtual machine (see Figure 1).

VMware vMotion Operations - Start

Figure 2: Wizard when starting a vMotion process from the context menu of the virtual machine

The difference between these two methods of opening the wizard is that in the latter method can also be used for Storage vMotion. Actually wizard even allows you to select the migration type, vMotion, Storage vMotion or cold migration (Figure 2).

If you decided for the drag and drop method, the resulting dialog is significantly shorter and you only have to choose the VMware vMotion priority. Incidentally, it is also possible to mark multiple virtual machines and migrate them all via drag and drop or context menu.

The context menu wizard asks you to select the target system and the resource pool (Figure 3).  

VMware vMotion - Select Target

Figure 3: Select the target Host, Cluster or Resource Pool for the VM

Change network

Since VMware vSphere 6 vMotion allows you to change the virtual machine network, making it possible to perform a migration between systems having different portgroups configured. That makes it very convenient if you migrate across datacenter (Figure 4).

vSphere 6 vMotion - select the Network

Figure 4: Select the target portgroup (network) for the VM

The VMware vMotion priority should in most cases be configured to reserve cpu for optimal vMotion performance so that sufficient resources can be guaranteed on the target system and the vMotion process can complete as quickly as possible. Otherwise the vMotion process will be immediately broken off as soon as the required resources on the target system are not available or massively slowed down.

Dialog for configuring vMotion priority

Figure 5: Dialog for configuring vMotion priority

Choosing continue with available CPU resources can noticeably slow down the vMotion process since the process will wait for resources instead of directly reserving them. Therefore the migration will also always be performed, even in problematic cases, with an overly high main memory usage. The virtual machine can thus even be temporarily unavailable in case the resources on the target system are not accessible in time.

Schedule vMotion

vSphere 6 - schedule vMotion

Figure 6: Schedule vMotion

vSphere 6 added another great feature to vMotion: scheduling! Now you can chose to either run the migration process by clicking OK or schedule it to be triggered by a certain event or time. You just need to select Change next to the configured Scheduler row.

As soon as the vMotion process is started you can follow the steps of the process by monitoring the events on the host systems and virtual machines. This also allows you to check the complete time that was taken by the process upon completion. During the process it is not possible to monitor the remaining time required to finish.

In the standard configuration only four (1 Gbit network) or eight (10 Gbit network) simultaneous vMotion migrations are allowed per host and 128 vMotion migrations are allowed per VMFS datastore.

You can find more information about the VMware vSphere configuration maximums here

Security

The vMotion data transfer uses plain text. Therefore it is advisable for both performance and security reasons to use a dedicated network for vMotion traffic. vMotion traffic should never be mixed with network traffic from the virtual machine, meaning they should never be transmitted over the same network adapter or at the very least a VLAN separation should be configured.

VMware vMotion monitoring

The knowledge about these VMware vMotion Special Features as well as the knowledge how to use them go hand in hand.

To get a good feeling about your daily vMotion tasks and how long they take, check out our 

VMotion/svMotion Report

CNIL
Metrics and Logs

(formerly, Opvizor Performance Analyzer)

VMware vSphere & Cloud
PERFORMANCE MONITORING, LOG ANALYSIS, LICENSE COMPLIANCE!

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

Goal:

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

Implementation:

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

Goal:

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.

Implementation:

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

Goal:

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, …)


Implementation:

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

Goal:

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.

Implementation:

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

Goal:

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.

Implementation:

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.