When you need to change a VM’s host server, you can either move or migrate the VM:
Migrating: For host server availablility.
Transfers just the VM’s instance in RAM from one host server to another (essentially keeping the VM live), assuming that both hosts have shared access to the VM’s files and image. When you shut down the VM and later restart it, it restarts from the new host server. In other words, its files are not moved, but it now has a new host server association.
Moving: For host resource reallocation. For more information, see Section 5.9, Moving VMs.
Physically moves all of the VM’s files and its image from one host server to another while the VM is shut down. When you start the VM, it starts from its new repository.
Hyper-V migrations are not supported.
Migration of Xen VMs with Fibre Channel SAN disks is not supported.
If you have a secondary iSCSI disk defined for a VM, migration is supported between two host servers only if both are connected to the same iSCSI disk.
Review the following sections to migrate a VM:
In order for a migration to work, the following conditions must exist:
Xen must be configured to allow for migrating its VMs. For more information setting up Xen for a live migration, see Option 2 in Novell AppNotes.
For vCenter (ESX ) VM migrations, both the source and target machines must have VMotion enabled. ESX servers with vCenter are migrated faster because VMotion allows the migration to occur live, instead of losing some time for suspending the VM as is necessary for ESX migrations.
The two host servers involved in the migration must have access to the shared repository where the VM’s files and image reside.
Every entity involved must have the same architecture, such as 32-bit or 64-bit, mount points, and routing of network connections to the virtual network.
For example, a 64-bit paravirtualized guest created on a 64-bit hypervisor can be migrated to another host server running a 64-bit hypervisor, but not a 32-bit hypervisor. Or, you can create a 32-bit VM on a 64-bit hypervisor and migrate it to another 64-bit hypervisor host. In other words, you cannot start a VM on a host that has a different architecture from the host where the VM was created.
The host server cannot be fully utilized, because it would be incapable of hosting the VM.
The host server cannot have met its maximum allowable VMs. This value is set in the Development Client in the
field. The default is 8. It doesn’t matter whether the maximum VMs it is already hosting are fully utilizing it.A host server cannot be disabled by having its
check box deselected in the Development Client. By default, this check box is enabled.A host server is only available if it is not out of sync, which can occur if it is manually accessed or manipulated via a third-party tool. However, you can resynchronize the host server with the Orchestrate Server.
If the VM has a CD-ROM or DVD-ROM defined for it, they must be accessible through shared storage to the target host server. Otherwise, the CD-ROM or DVD-ROM will not be included in the migration and the migrated VM cannot start again after it has been stopped. In that case, you should remove the CD-ROM or DVD-ROM from the VM before continuing with Section 5.10.2, Migrating a VM.
Some conditions are automatically enforced with constraints, such as operating system, shared storage, xend configuration, and possibly the architecture.
During migration:
Even if the above criteria are met by only one host server, the Migrate Virtual Machine dialog box is displayed.
If the criteria are met by multiple host servers, you can either select a host server, or select to have the VM Client automatically select the host server.
If no host servers meet the requirements, the No Migrate Target Available dialog box is displayed, indicating that you need to resolve the issues to continue.
NOTE:For ESX migrations, the VM is suspended, it is migrated from one host to another, then it is provisioned.
To migrate a VM, you need to prepare the host servers, then migrate the VM.
Make sure that each host has access to the shared repository to be used for the VM’s files.
In the VM Client, click the view, select the VM to migrate, then do one of the following:
Click the button.
Click
> .In the
view, right-click the selected VM, then select .If only one host server is available, it is automatically used and you can continue with Step 4. Otherwise, the following dialog box is displayed if there are two or more target host candidates:
If you have multiple host servers to select from, do one of the following:
Leave the
check box selected.The
option allows the Orchestrate Server to automatically select a host server from those that are available by using a ranking criteria, such as architecture similarity and available CPU and RAM resources. For example, hosts are selected that meet the architecture requirements, the cost of moving information is then considered, and if there is still no clear winner, then the least loaded machine is selected. The ranking criteria can be affected by policies that you might have set in the Development Client.Select the VM host to which you want to migrate the VM.
These options are mutually exclusive, meaning that selecting one disables the other.
If you do not yet have a valid host server to migrate to, the following dialog box is displayed:
Review the issues, resolve them, then repeat from Step 1.
Click
.You can view the migration progress in any of the following ways:
Double-click the VM being migrated, click the
tab, then double-click the entry related to the migration process that has the icon next to it. The Event Log Details dialog box is displayed and is automatically updated as events occur.Observe messages at the bottom of the VM Client interface.
Click
> to open the Progress window.View its progress in the Development Client.
tab of theWhen the migration has completed, the VM continues to run on its new host.
ESX migrations might take a bit longer because the ESX server must be suspended in order to migrate its RAM content.