Re: [Qemu-devel] Migration design planning

[Juan Quintela <quintela@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.
>
> 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.

After this week I will take a look at this series.

>
> 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.

How big is it?
And what is a normal rate of dirtying of that bitmap?


> 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.

To make a good evaluation, we need:
- how big are normally that bitmaps
- what is a typical/worst dirty rate

I guess we can go from them.

And you say that you don't care a lot about lossing the bitmap.  "Not
big deal" here means?

Size here is also important, normally we have around 1-2MB of data for
the last stage.  If size is much bigger than that amount, we will
really, really want it to be send "live".


Wondering about the second approach, it is possible for you:

- do normal migration
- run on destination with a new empty bitmap
- transfer the bitmap now
- xor the two bitmaps

Or this is exactly what you are proposing on the second example?  If it
is, what is the error recovery if we lost connection during the transfer of the
bitmap, can you recover (I guess this is the "not big deal") part.

Does this makes any sense?

Later, Juan.

PD.  It is clear by now that I don't understand how you do the backup!