<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">(2013年10月08日 00:45), Cole Robinson wrote: </div> <blockquote cite="mid:5252D72F.2060508@redhat.com" type="cite"> <pre wrap="">On 10/05/2013 10:59 AM, Eiichi Tsukata wrote: </pre> <blockquote type="cite"> <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:devel@etsukata.com"><devel@etsukata.com></a> --- ui/migrate.ui | 61 ++++++++++++++++++++++++++++++++++++++++++++++-- virtManager/domain.py | 7 +++++- virtManager/migrate.py | 41 +++++++++++++++++++++++++++++--- virtManager/uihelpers.py | 20 ++++++++++++++++ 4 files changed, 123 insertions(+), 6 deletions(-) </pre> </blockquote> </blockquote> Thanks for reviewing Cole, <blockquote cite="mid:5252D72F.2060508@redhat.com" type="cite"> <pre wrap=""> 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) </pre> </blockquote> 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. <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="https://www.redhat.com/archives/libvir-list/2013-September/msg00751.html">https://www.redhat.com/archives/libvir-list/2013-September/msg00751.html</a> I didn't know block migration doesn't work with libvirtd tunnel. That makes it more difficult for users to use the feature correctly. <blockquote cite="mid:5252D72F.2060508@redhat.com" type="cite"> <pre wrap=""> 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.</pre> </blockquote> 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: <a class="moz-txt-link-freetext" href="http://wiki.qemu.org/Documentation/CreateSnapshot">http://wiki.qemu.org/Documentation/CreateSnapshot</a> <blockquote cite="mid:5252D72F.2060508@redhat.com" type="cite"> <pre wrap=""> But just exposing things as-is will make my life harder while not really adding anything for users beyond what virsh provides. - Cole </pre> </blockquote> 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 </body> </html>