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@xxxxxxxxxxxx> > >>--- > >> 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 :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
