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

[Daniel P. Berrange]

On Tue, Oct 08, 2013 at 11:26:14PM +0900, Eiichi Tsukata wrote:
> (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

One other limitation of block migration is that it is all or nothing
in terms of the disks copied.

So if you have a VM that has one disk on a SAN that is accessible
to both hosts and one disk on a file only visible to a single host,
it is going to copy data for both disks, even though it should only
do the latter.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|