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(-) > 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) 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. But just exposing things as-is will make my life harder while not really adding anything for users beyond what virsh provides. - Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
