* John Snow (js...@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 / dgilb...@redhat.com / Manchester, UK
