Skip to main content

Moving a virtual machine between ESXi hosts with different processor types

 Purpose

This article provides steps to move a VM from one processor type host to another processor type host when:
  • EVC is not available
  • vCenter is not in the environment,
  • vCenter is the VM that needs to be migrated in it's own workload.
Resolution

Moving a VM when there is shared storage between the hosts

Warning: If the virtual machine being migrated is running on a Virtual Distributed Switch (vDS), move the virtual machine to a standard vSwitch before proceeding with these steps.

 
To move a VM between hosts when there is shared storage:
  1. Shut down the VM after making a note of the host on which it is running and the datastore on which it is residing. Both can be found on the Summary tab of the virtual machine.
  2. Connect with the Host UI Client directly to the source ESXi host on which the VM was running.
  3. Right-click the VM and click Remove from Inventory.
  4. Connect with the Host UI Client directly to the destination ESXi host on which you want the VM to run.
  5. Right-click the datastore on which the VM is stored and click Browse datastore.
  6. Open the directory for VM, right-click the .vmx file and click Add to Inventory.
  7. Power on the virtual machine.

Note: The first time you power up a moved virtual machine, a uuid.altered message displays. Select I moved it to keep the existing uuid. If it was a vCenter Server that was moved using the above directions, there may be a slight delay for vCenter Server virtual machine to correct its own location in the vCenter Server database.
 

Moving a VM when the hosts do not have shared storage

To move a VM between hosts when storage is not shared, perform one of these options:

Note: These options require the MAC of the virtual machine to be manually set. For more information, see Setting a static MAC address for a virtual NIC (219).

For the majority of your workload with vCenter, it can be powered off, and you can complete a xvMotion using the web client by selecting you want migrate compute and storage. This feature does not require licensing that needs storage vMotion, as we do not use the storage vMotion stack for this type of migration. If your workload is the vCenter itself, or vCenter cannot be utilized, below are some other scenarios:

  • Clone the VM from one host to another:
  1. Select the VM from the Inventory.
  2. Right-click the VM and click Clone.
  3. Select the destination ESXi host.
  4. Power off the VM on the source host.
  5. Power on the VM on the destination ESXi host.
NOTE: Make sure we have required license for hot cloning.
  • Export VM as an Open Virtual Machine Format (OVF):
  1. Connect the Host UI Client to the ESXi host running the VM
  2. Power off the VM
  3. Click File > Export > Export OVF Template
  4. Connect the vSphere Client directly to the destination ESXi host
  5. Click File - Deploy OVF Template.
  6. Power on the VM

Comments

Popular posts from this blog

Error [403] The maximum number of sessions has been exceeded in the H5 client during login or logout

  Symptoms In virgo log, you see messages similar to: [2020-05-19T07:25:45.285Z] [ERROR] http-nio-5090-exec-130 72026859 142953 501051 com.vmware.vise.security.spring.DefaultAuthenticationProvider logout failed for sessionId 142953, clientId 501051 java.lang.IllegalStateException: The specified cardinality of 1..1 for osgi:reference implementing com.vmware.vcenter.apigw.api.ApiGatewaySessionManager in bundle com.vmware.h5ngc requires that exactly one OSGI service satisfies the filtering criteria but no such service was found.         at com.vmware.o6jia.context.ExternalServiceTargetSource.getTarget(ExternalServiceTargetSource.java:99)         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:192)         at com.sun.proxy.$Proxy159.logout(Unknown Source)         at com.vmware.vise.security.spring.DefaultAuthenticationProvider.logoutInternal(DefaultAuthenticationProvider.java:548)         at c

Investigating virtual machine file locks on ESXi

      Details Adding an existing virtual machine disk (VMDK) to a virtual machine that is already powered on fails.                 Failed to add disk scsi0:1. Failed to power on scsi0:1   Powering on the virtual machine results in the power on task remaining at 95% indefinitely. Cannot power on the virtual machine after deploying it from a template. Powering on a virtual machine fails with an error: Unable to open Swap File Unable to access a file since it is locked Unable to access a file <filename> since it is locked Unable to access Virtual machine configuration In the /var/log/vmkernel log file, you see entries similar to: WARNING: World: VM xxxx: xxx: Failed to open swap file <path>: Lock was not free WARNING: World: VM xxxx: xxx: Failed to initialize swap file <path>   When opening a console to the virtual machine, you may receive the error: Error connecting to <path><virtual machin

"Performance data is currently not available for this entity" viewing the performance tab

  Symptoms While accessing the performance tab and navigating to Overview, you see: No data available   The data for Real time, but fails to retrieve it for past 1 day, week, month or year.  While selecting the advance parameter in performance tab, you see: Performance data is currently not available for this entity Cause This issue is caused by the vCenter Server database (Postgress) containing a stale/future time stamp reference for the ESXi host when the data was collected. For vCenter Servers using SQL, see  "Performance data is currently not available for this entity" error after updating rollup in vSphere Resolution Backup the vCenter database. For more info