Re: [libvirt] [Qemu-devel] Killing block migration in qemu?
On Wed, Aug 17, 2011 at 5:51 PM, Paolo Bonzini <pbonzini@redhat.com> 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
On 08/17/2011 10:21 AM, Stefan Hajnoczi wrote:
On Wed, Aug 17, 2011 at 5:51 PM, Paolo Bonzini<pbonzini@redhat.com> 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?
Yes, the problem is that it is much harder to move block migration to a separate thread. It will use a separate coroutine loader and busy loop on coroutine locks while holding the iothread. I'm not even sure it won't deadlock. Block streaming is anyway asynchronous, so it does not hurt that it stays in the I/O 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?
The code is fine, but it conflicts with a bunch of goals we have for RAM live migration.
This sounds reasonable. In fact we can do both pre-copy and post-copy block migration using streaming (+mirroring).
Right, post-copy is just another name of copy-on-read. Pre-copy RAM migration and post-copy block migration might be the best of both worlds in many settings, since pre-copy block migration takes ages. Paolo
participants (2)
-
Paolo Bonzini -
Stefan Hajnoczi