Re: [Qemu-devel] Migration design planning

[John Snow <jsnow@redhat.com>]

On 03/02/2016 11:46 AM, Dr. David Alan Gilbert wrote:
> * 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
> 

*usually* pretty small, could be ~reasonably large~ (4MiB per 2TiB) and
we could have almost arbitrarily many -- though expected use case is
maybe 1-2 bitmaps per drive (or perhaps 1-2 bitmaps per node) as our
expected eventual use case.

I don't really have an answer for why we haven't pursued this other than
"We already have two unreviewed RFC series for migrating these, why are
we going to write a third?"

--js

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