CrossPoolMigrationv3

This page describes a possible design for Cross-pool migration (which also works for within-pool migration with and without shared storage).

This design has the following features:

1. disks are replicated between the two sites/SRs using a "replication service" which is aware of the underlying disk structure (e.g. in the case of .vhd it can use the sparseness information to speed up the copying)
2. the mirror is made synchronous by using the *tapdisk* "mirror" plugin (the same as used by the existing disk caching feature)
3. the pool-level VM metadata is export/imported by xapi
4. the domain-level VM metadata is export/imported by xenopsd

See the following diagram:

This design has the following advantages:

1. by separating the act of mirroring the disks (like a storage array would do) from the act of copying a running memory image, we don't need to hack libxenguest. There is a clean division of responsibility between managing storage and managing running VMs.
2. by creating a synchronous mirror, we don't increase the migration blackout time
3. we can re-use the disk replication service to do efficient cross-site backup/restore (ie to make periodic VM snapshot and archive use an incremental archive)

Proposed APIs

1. VM.migrate_receive(Host host, SR sr, Map(String,String) options): Map(String, String)
   1. host: the host to move the running VM to
   2. sr: the SR to replicate the VM's disks to
   3. options: for future advanced options
   4. the return value should be considered an abstract token, identifying the receiver. The token should be passed to the transmitter.

1. VM.migrate(VM vm, Map(String, String) dest, Bool live, Map(String, String) options)
   1. vm: the running VM to migrate
   2. dest: the result of a previous VM.migrate_receive call
   3. live: if true this is a "live" migration
   4. options: for future advanced options