In many ways, a move is similar to a cloning process, because the source virtual machine is used as a template to create the destination virtual machine. Once the creation of the destination virtual machine is complete, the source virtual machine is deleted.

For this reason, moving a virtual machine involves using a clone customizer. During the move process, you can use a clone customizer to:

The network information is not changed when moving a virtual machine, so you cannot move VNICs between networks. Any network changes you make in a clone customizer are ignored when moving a virtual machine. This allows you to preserve the virtual machine in its original state, while moving the configuration file and storage to a different repository.

It is also important to understand that when moving a virtual machine that has shared virtual disks or an attached virtual CD-ROM device, the data for these objects is actually copied across repositories rather than moved. This is because if an object is shareable, it is not possible to determine whether that object may be needed by another virtual machine that is not being moved. Therefore, if your virtual machine has any attached ISOs or shared virtual disks and you complete a move operation, you may wish to manually remove these objects from the source repository if you know that they are no longer in use.

Moving Virtual Machines Between Local Repositories.  Oracle VM Manager does not allow you to move a virtual machine directly from one local repository to another local repository if that virtual machine uses virtual disks. Note that it is possible to effectively move a virtual machine from one local repository to another while it is running by performing a live migration as described in Migrating Virtual Machines. However, if the virtual machine is stopped, you must move that virtual machine and the virtual disks from the local repository of the source Oracle VM Server to a shared repository. You can then move the virtual machine and the virtual disks from the shared repository to the local repository of the destination Oracle VM Server.

For example, your environment includes a server pool with two Oracle VM Servers, server A and server B. Both servers use repositories that are hosted on disks that are local to each server. Server A cannot access the repository that is local to server B. Conversely, server B cannot access the repository that is local to server A.

On server A you have a virtual machine that uses a virtual disk, or a file in storage that is presented to the virtual machine as a disk. To move the virtual machine from the repository for server A to the repository for server B, you must use an intermediate shared repository that both server A and server B can access.

Related Information. 

Live migrations can occur only between Oracle VM Servers within the same server pool. If the virtual disks for a virtual machine reside on shared storage, then each Oracle VM Server within the server pool has access to the virtual disks. As a result, live migrations of virtual machines in this scenario are straightforward because the virtual disks do not need to change to a different repository.

However, to perform live migrations between Oracle VM Servers that use local storage, you must also migrate the virtual disks from the source server's local repository to the destination server's local repository. Because the local storage is specific to each Oracle VM Server, it is not possible to migrate a virtual machine from one Oracle VM Server to another without migrating the virtual disks.

The following restrictions apply to live migrations that include migrating the virtual machine's storage:

In Oracle VM Release 3.4.2, the following rule was added to prevent failure of live migration and subsequent issues with the virtual machine environment:

Oracle VM Manager does not allow you to perform a live migration of a virtual machine to or from an instance of Oracle VM Server with a Xen version earlier than xen-4.3.0-55.el6.22.18. This rule applies to any guest OS.

# rpm -qa | grep "xen" 

In addition to rules that prevent live migration in specific cases, Oracle VM Manager includes several safeguards to prevent live migration where the operation might result in resources becoming unavailable to any virtual machine in the server pool. For instance, if the virtual machine is using a locally hosted ISO, live migration fails. Equally, in the case where a locally hosted virtual disk is shared between two or more virtual machines on the same Oracle VM Server, live migration of any of these virtual machines also fails since the locally hosted virtual disk cannot be migrated without affecting the other virtual machines. In the event that live migration fails, the target repository is automatically cleaned.

During the migration of a virtual machine from one Oracle VM Server to another, Oracle VM Manager also tests the target Oracle VM Server to ensure that any LUNs used by the virtual machine are actually available. This includes a check that the path exists and a check to ensure that the path is actually up.

In the event that the target Oracle VM Server selected for a live migration with storage becomes unavailable during the migration, a rollback process is attempted to revert the environment to its state prior to the migration. If the target Oracle VM Server remains offline during the entire rollback process, some manual steps may be required to properly revert the environment, although the environment should function normally even while these steps have not been performed. This rollback process is described in more detail in the section titled Recovering From A Failed Local Virtual Machine Migrationin the Oracle VM Administrator's Guide.

Migrating Multiple Virtual Machines.  You can migrate one or more virtual machines at a time. When migrating multiple virtual machines, the migrations are performed serially and not concurrently, so one migration is performed, then the next, until all the migrations are completed. Cross-server pool migration is allowed, though the virtual machines must first be stopped. A virtual machine must also be in a stopped state before migrating it off of any server (an Unassigned Virtual Machine). When you migrate a virtual machine to another server pool, the virtual machine is not deployed to a particular Oracle VM Server until you start the virtual machine, then the placement strategies for the virtual machine depends on the Oracle VM Server roles, and destination server pool policies such as Distributed Resource Scheduler (DRS) and Distributed Power Management (DPM). See Section 6.2, “What are Server Roles?” for information on Oracle VM Server roles, and Section 6.12, “What are Server Pool Policies?” for information on server pool policies.

Inbound Migration Locks.  If you have set the inbound migration lock feature to disallow new virtual machines on an Oracle VM Server, then any automatic migration policies you set are restricted from migrating virtual machines, or creating new ones on that server. See Section 7.12, “How Can I Protect Virtual Machines?” for more information on using the inbound migration lock feature.

CPU Compatibility.  The CPU family and model number of the source and destination computers must be compatible in order to perform live migration. This means, for instance, that you cannot migrate a virtual machine from an x86-based server pool to a SPARC-based server pool, or vice versa. Equally, you cannot perform a live-migration within the same x86-server pool, if the servers have different CPU families or model numbers. For more information on CPU compatibility, please see Section 6.14, “What are Server Processor Compatibility Groups?”.