CrossPoolMigration

To Do: Has this been implemented? If so, it should be moved to Designs in the XAPI Devel Index

This page describes current work to make

• Cross-pool migration
• Storage migration

work on XCP

The following designs were considered:

1. CrossPoolMigrationv1: based on DRBD
2. CrossPoolMigrationv2: based on tapdisk log-dirty
3. CrossPoolMigrationv3: based on tapdisk mirroring

Choosing a design

The following properties are desired:

1. the chosen design should exploit all available disk structure information to minimise bandwidth and be fast
2. the chosen design should clearly separate the storage migration from the domain migration, avoiding the need to add additional hooks into the domain memory send/receive code (in libxenguest)
   • this should also make it easier to use libxl functions in future
3. the chosen design should be as "live" as possible i.e. it should avoid extending the migration downtime
4. the chosen design should be compatible with *dom0 disaggregation*, in particular where some storage elements are not in dom0

Proposed choice

The design based on tapdisk mirroring CrossPoolMigrationv3 is the proposed choice. It has the following benefits:

1. it allows vhd-based storage backends to copy only disk blocks that cannot be found on the destination SR
   1. furthermore if a migration fails, many of the blocks will probably have been copied so subsequent migrations may be faster
2. it separates "mirror creation" from "domain migration", so the libxenguest is unmodified
3. by creating a mirror in advance, the code running in the "migration downtime" is unmodified
4. *unknown*: the ease of disaggregating dom0 will depend on the exact APIs used, these are still TBD