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