On 05/21/2015 09:57 AM, Denis V. Lunev wrote:
On 21/05/15 16:51, Vladimir Sementsov-Ogievskiy wrote:
Hi all.
Hmm. There is an interesting suggestion from Denis Lunev (in CC) about
how to drop meta bitmaps and make things easer.
method:
start migration
disk and memory are migrated, but not dirty bitmaps.
stop vm
create all necessary bitmaps in destination vm (empty, but with same
names and granularities and enabled flag)
start destination vm
empty bitmaps are tracking now
start migrating dirty bitmaps. merge them to corresponding bitmaps
in destination
while bitmaps are migrating, they should be in some kind of
'inconsistent' state.
so, we can't start backup or other migration while bitmaps are
migrating, but vm is already _running_ on destination.
what do you think about it?
the description is a bit incorrect
- start migration process, perform memory and disk migration
as usual. VM is still executed at source
- start VM on target. VM on source should be on pause as usual,
do not finish migration process. Running VM on target "writes"
normally setting dirty bits as usual
- copy active dirty bitmaps from source to target. This is safe
as VM on source is not running
- "OR" copied bitmaps with ones running on target
- finish migration process (stop source VM).
Downtime will not be increased due to dirty bitmaps with this
approach, migration process is very simple - plain data copy.
Regards,
Den
I was actually just discussing the live migration approach a little bit
ago with Stefan, trying to decide on the "right" packet format (The only
two patches I haven't ACKed yet are ones in which we need to choose a
send size) and we decided that 1KiB chunk sends would be appropriate for
live migration.
I think I'm okay with that method, but obviously this approach outlined
here would also work very well and would avoid meta bitmaps, chunk
sizes, migration tuning, convergence questions, etc etc etc.
You'd need to add a new status to the bitmap on the target (maybe
"INCOMPLETE" or "MIGRATING") that prevents it from being used for a
backup operation without preventing it from recording new writes.
My only concern is how easy it will be to work this into the migration
workflow.
It would require some sort of "post-migration" ternary phase, I suppose,
for devices/data that can be transferred after the VM starts -- and I
suspect we'll be the only use of that phase for now.
David, what are your thoughts, here? Would you prefer Vladimir and I
push forward on the live migration approach, or add a new post-hoc
phase? This approach might be simpler on the block layer, but I would be
rather upset if he scrapped his entire series for the second time for
another approach that also didn't get accepted.
--js