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

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



(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 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

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