VCP 5 – Objective 5.4 – Migrate Virtual Machines

Identify ESXi host and virtual machine requirements for vMotion and Storage vMotion

• Each host must be correctly licensed (essentials plus and up) for vMotion and Enterprise and up for Storage vMotion
• Each host must meet the shared storage requirements for vMotion
  • Datastores must be available to all the hosts participating within the migration
• Each host must meet the networking requirements for vMotion
  • Hosts must have a vmkernel port that has been assigned to vMotion.  This network must reside on the same subnet on both hosts.  It must also be named identically.  Also, the networks that the VMs are attached to must also reside on both hosts and be named the same.

VM Requirements

• Cannot vMotion VMs that are using RDMs for clustering purposes
• Cannot vMotion a VM that is backed by a device that isn't accessible to the target host.  I.E. A CDROM connected to local storage on a host.  You must disconnect these devices first.  USB is supported as long as the device is enabled for vMotion.
• Cannot vMotion a VM that is connected or backed by a device on the client.  You must also disconnect these first.

• Method of moving VMs while they are powered off.
• Can move to both a new host and a new storage location at the same time
• Gives you the ability to move across datacenters.

• Same options as cold migration, except the VM is placed in a suspended state before performing options rather than being powered off.

• When performing a vMotion the VM is powered on.
• Only moves VM from one host to another.  Does not perform Storage vMotion at the same time.

• Moves either a single disk or all disks of a VM to one ore more different datastores.
• Can also move the configuration (vmx) file of the VM.

Performing a Storage vMotion

1. Right Click VM and select Migrate
2. Select migration option (change datastore)
   • Change Host
   • Change Datastore
   • Change both Host and Datastore (Only supported with cold and suspended migrations).
3. Select a format for the target disk format.  Note, disks are only converted when being moved.  If a disk is left on the same datastore it will remain in the same format regardless of your choices made here.   Options include
   • Same as Source – Uses the same format as the original disk.  If you select this option when using a RDM in physical compatibility mode only the mapping file is migrated.  If the RDM is in virtual compatibility mode, the RDM will be converted to a VMDK.
   • Thin Provisioned – This will convert the source disk to a thin disk on the target datastore.  You cannot do this with a physical RDM, however this will convert a virtual RDM.
   • Thick – Will convert the source disk to thick.  Again, this can't be used on physical RDM but will convert a virtual RDM..
4. Select the datastore location to store the VM files Option to apply a VM Storage Profile exist on all options..  Options include
   • Store all virtual machine files in the same location on a datastore – Select  a datastore
   • Store all virtual machines files in the same Storage DRS Cluster – Select a Storage DRS Cluster.  Optionally at this point you can select the 'Disable Storage DRS for this VM' and select a datastore from within the cluster if you wish to disable SDRS on this VM
   • Store VM configuration files and disk in separate locations – Use this option to select different datastores or datastore clusters to store the vmx files and the virtual disk files.  You can also disable SDRS at this point as well.
5. DONE!

Performing a vMotion

1. Select the VM, right click and select Migrate
2. Select Change Host
3. Select the destination resource pool
4. Select a destination host or cluster.
5. Select you migration priority level
   • High Priority –
     • On hosts running version 4.1 or later vCenter will attempt to reserve resources on both the source and destination hosts to be shared amongst all vMotions.  Migrations will always proceed regardless of the resources that have been reserved.  
     • On hosts running 4.0 or later, vCenter will attempt to reserve a fixed amount of resources on both source and destination for each individual migration.  Migration will not proceed if resources are unavailable.
   • Standard Priority
     • On hosts running 4.1 or later, vCenter reserves resources on both the source and destination to be shared amongst all migrations.  Migrations will always proceed.
     • On hosts running 4.0 or later, vCenter attempts to reserve a fixed amount for each individual migration.  Standard Migrations always proceed but may be more slow.  Also, they may fail if insufficient resources are available
6. DONE.

There are a few other options which should be explained when migrating a VM

• Priority Levels are different for vMotion when using the web client.  They are as follows…
  • Reserve CPU for optimal vMotion Performance – vCenter will attempt to reserve resources on both the source and target hosts.  If the resources cannot be obtained, vMotion will not be initiated.
  • Perform with available CPU resources – vCenter will attempt to reserve the resources, if it cannot, it will still continue, however it may take longer.
• Instead of right click migrate, you select right click -> Inventory -> Migrate 
• When performing Storage vMotion with the web client there is no option to convert disk type nor apply a storage profile.

In all cases, vMotion performs a compatibility check before proceeding.  The compatibility check may display hard errors or warnings.  The following is what causes these.

Errors

• CPU is not compatible with the VMs requirements
• vMotion interfaces are not configured correctly
• CPU affinity is enabled on the VM
• Not enough licenses available
• VM has an RDM or vmfs volume that isn't shared across both hosts.
• Attached to a physical cd rom or floppy.

Warnings

• I believe warnings are just generated if you are configured for something that might cause an error, but it isn't attached or connected.