On Wed, Aug 17, 2011 at 5:51 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > following discussions yesterday with Juan Quintela and Marcelo Tosatti, here > is my humble proposal: remove block migration from qemu master. It seems to > me that keeping block migration is going to slow down further improvements > on migration. The main problems are: > > 1) there are very good reasons to move migration to a separate thread. Only > a limited amount of extra locking, perhaps none is needed in order to do so > for RAM and devices. But the block drivers pretty much need to run under > the I/O thread lock, and coroutines will not help if the I/O thread is taken > by another thread. It's hard/unreliable/pointless to ping-pong migration > between threads. The image streaming approach will also run in the I/O thread for the mid-term future. Is the problem that the block migration code today is too tied into the actual migration code path and therefore stops from using it when migration happens in a separate thread? > > 2) there already are plans to reimplement block migration... it's called > streaming :) and not coincidentially it reuses some of the block migration > code. What are the concrete issues with the existing block migration code? I'm not disagreeing that we should move to a streaming approach but I simply don't know the details of the existing block migration code. > Here is how it would go: This sounds reasonable. In fact we can do both pre-copy and post-copy block migration using streaming (+mirroring). Stefan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list