Novell PLATESPIN ORCHESTRATE 2.0.2 - ADMINISTRATOR REFERENCE 06-17-2009, Руководство для клиента, Страница: 110 / 164

110 PlateSpin Orchestrate 2.0 VM Client Guide and Reference
no
vd
ocx
(e
n)
13
Ma
y 20
09
5.10 Migrating VMs
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,” on page 108 .
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:
Š
Section 5.10.1, “Prerequisites,” on page 110
Š
Section 5.10.2, “Migrating a VM,” on page 111
5.10.1 Prerequisites
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 (http://www.novell.com/communities/
node/5050/xen-virtual-machine-migration) .
Š
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.