[virt-tools-list] [PATCH] virt-manager: Add block migration support

[Eiichi Tsukata]

(2013?10?08? 00:45), Cole Robinson wrote:
> On 10/05/2013 10:59 AM, Eiichi Tsukata wrote:
>> This patch adds block migration support. There are two modes: full
>> disk copy and incremental disk copy, which correspond to libvirt
>> virDomainMigrate API's flags, VIR_MIGRATE_NON_SHARED_DISK and
>> VIR_MIGRATE_NON_SHARED_INC. These flags are mutually exclusive,
>> so GUI is implemented by ComboBox.
>>
>> Signed-off-by: Eiichi Tsukata <devel at etsukata.com>
>> ---
>>   ui/migrate.ui            | 61 ++++++++++++++++++++++++++++++++++++++++++++++--
>>   virtManager/domain.py    |  7 +++++-
>>   virtManager/migrate.py   | 41 +++++++++++++++++++++++++++++---
>>   virtManager/uihelpers.py | 20 ++++++++++++++++
>>   4 files changed, 123 insertions(+), 6 deletions(-)
>>

Thanks for reviewing Cole,
> At a glance the code looks fine. But I'm wary of exposing storage migration in
> the UI for the following reasons:
>
> 1) The oldest storage migration code in qemu is known inefficient, not really
> maintained, and usage is discouraged by qemu devs. So I'd want to
> conditionally expose it depending on libvirt and qemu being new enough to do
> the old style.
>
> 2) It has serious usability issues: a) you need to pre-create storage file
> stubs on the destination (there are libvirt patches for this) and b) doesn't
> work with tunnelled migration (which is the simplest option for end users but
> isn't a blocker)

Yes, we need to pre-create storage file with qemu-img command before
block migration. The following libvirt patches are probably that you are
mentioning.
https://www.redhat.com/archives/libvir-list/2013-September/msg00751.html

I didn't know block migration doesn't work with libvirtd tunnel. That makes
it more difficult for users to use the feature correctly.

> We will definitely get bug reports about the last bit if we don't at least
> stick a warning in the UI about the caveats. So maybe if someone selects
> storage migration we unhide a little warning box that explains things (we
> could even explain 'this is the old qemu method and might suck', and when all
> the libvirt bits are in place we can do a version check and not show the error
> anymore.
>
> Also, I don't really understand when someone would want to use NON_SHARED_DISK
> vs NON_SHARED_INC, so if a user asks I don't know what to tell them. Maybe
> someone can enlighten me.

NON_SHARED_DISK flag is used to copy all the storage files with VM
migration. This is the simplest usage of block migration.

NON_SHARED_INC flag is used to copy only snapshot image of the
VM storages. If you use NON_SHARED_INC flag, the same backing file
needs to be shared between source and destination. It takes less time
to migrate with NON_SHARED_INC because only the difference of current
storage file and backing file is transferred. It's very useful.

For qemu snapshot, please see the following page:
http://wiki.qemu.org/Documentation/CreateSnapshot

>
> But just exposing things as-is will make my life harder while not really
> adding anything for users beyond what virsh provides.
>
> - Cole

Anyway, the current libvirt has usability issues you mentioned, so
it may be too early to send this patch.
I'll rewrite the patch when libvirt solved the issues.

- Eiichi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20131008/61a9b0d4/attachment.htm>