Re: [Qemu-devel] Migration design planning

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* John Snow (jsnow@redhat.com) wrote:
> 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.

There's a question I remember asking before, but I don't remember the answer.
Given the size of these bitmaps (i.e. pretty small), why not make them
RAMBlocks that aren't mapped to the guest RAM (we have one example; the ACPI
config); if you did that, then they'd automatically get migrated with the
existing migration code.

Dave

> 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
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK