Archive/Storage XenMotion

From Xen
(Redirected from Storage XenMotion)
Jump to: navigation, search

What is Storage XenMotion?

Storage XenMotion (SXM) is an extention to the existing XenMotion live VM migration feature, which allows VMs to be migrated between XCP/XenServer hosts in a resource pool. SXM extends this feature by removing the restriction that the VM can only migrate within its current resource pool. We now provide the option to live migrate a VM’s disks along with the VM itself: it is now possible to migrate a VM from one resource pool to another, or to migrate a VM whose disks are on local storage, or even to migrate a VM’s disks from one storage repository to another, all while the VM is running.

What can I do with this feature?



How does it work?




How does it compare to other virtualization platforms?

One of the major differences in the way that XCP implements live storage migration is in the storage migration algorithm itself. Other virtualization products implement storage migration by performing copy-dirty, a process in which the entire disk is copied once, and then any disk blocks that have been written to during that initial copy, called “dirty blocks,” are copied as well. This process repeats until there are very few dirty blocks left, at which point the VM is migrated as usual, with the remaining storage copied over with the migrating VM. This is effectively like snapshotting and copying disks repeatedly, until the difference between the new snapshots is very small.

XCP’s snapshot/mirror operation is unique. In Storage XenMotion, disk writes are written synchronously to both the source and the destination storage repositories. For some workload, e.g. write intensive workloads, the synchronous mirroring approach enables us to minimize VM downtime by avoiding a potentially lengthy stop-and-copy phase.

How to migrate?

The command you are looking for is "xe vm-migrate". Below is the detail of what each option means to the migration.

migrate the VM without shutting it down
host= or host-uuid=
the name/uuid of the remote host if in the same pool
the network address of the remote master host
the remote username
the remote password
the destination storage pool you want the VM to be migrated to
parameter take the form 'vif:<source vif uuid>=<dest network uuid>'
parameters take the form 'vdi:<source vdi uuid>=<dest sr uuid>'
examples would be uuid=00000000-0000-0000-0000-000000000000 or vm=vmNameHere