Moving a Virtual Machine to Another Repository
You can move a non-running virtual machine from one repository to another. During the move you can specify where the disks should be moved to using a clone customizer. If you keep the clone customizers to the default settings (the same as the original virtual machine), a move is essentially the same as migrating the virtual machine to another Oracle VM Server. You can change the location of disks and the virtual machine configuration file to another storage repository when you move a virtual machine using a clone customizer.
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.
Migrating Virtual Machines Between Oracle VM Servers
Migrating a virtual machine is a process to move a virtual machine from one Oracle VM Server, or server pool, to another. If the virtual machine is running during the migration, the applications continue to run, uninterrupted and this is called live migration. This feature is important, and useful, when the existing Oracle VM Server may be out of commission (if HA is enabled), or on a planned shutdown for maintenance purposes. Live migration can only be performed within the same server pool, so a running virtual machine cannot be moved out of its server pool. Live migration does not require HA to be enabled; it can occur in a server pool simply by selecting a running virtual machine and migrating it, independently of whether or not the server pool is clustered and/or whether the virtual machine has its HA flag set.
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.11, “What are Server Pool Policies?” for information on server pool policies.
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.11, “How Can I Protect Virtual Machines?” for more information on using the inbound migration lock feature.
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.13, “What are Server Processor Compatibility Groups?”.