Re: [Qemu-devel] Killing block migration in qemu?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]