[Qemu-devel] Migration design planning

[John Snow]

Hi Juan;
We need your assistance in reviewing two competing designs for migrating
some block data so we can move forward with the feature.

First, some background:

What: Block Dirty Bitmaps. They are simple primitives that keep track of
which clusters have been written to since the last incremental backup.

Why: They are in-ram primitives that do not get migrated as-is alongside
block data, they need to be migrated specially. We want to migrate them
so that the "incremental backup" feature is available after a migration.

How: There are two competing designs, see below.


Design Option #1: Live Migration

Just like block data and ram, we make an initial pass over the data and
then continue to re-transmit data as necessary when block data becomes
dirtied again.

This is a simple, bog-standard approach that mimics pretty closely how
other systems are migrated.

The series is here from November:
https://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg02717.html

Most of the block-specific stuff has been reviewed, but it never got any
reviews by the migration maintainers. It's reasonably rotted by this
point, but it probably would not be a herculean effort to revive it.


Design Option #2: "Postcopy" Migration

https://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg02793.html

The concept here is that incremental backup data can be treated simply
as best-effort; if it is lost, it's not a big deal. We can reconstitute
the data or simply start a new incremental backup sync point with a full
backup.

The idea then is that instead of the incremental live migration, we just
wait to copy the bitmap until after the pivot and send it all at once.
This is faster and a bit more efficient, and will scale pretty nicely to
even quite large bitmaps.



What I'd like from you: a broad acknowledgment of whether or not you
feel the Postcopy solution here is tenable, so we know which solution to
pursue. If we can get an ACK to one or the other method, we can
exhaustively review it from our end before handing it back to you for a
comprehensive migration review. We would like to see this feature hit
2.6 if possible as the designs have been on-list for quite some time.

Thanks,
--John Snow