Re: [libvirt] [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps

On Wed, Aug 10, 2011 at 02:27:41PM -0500, Anthony Liguori wrote: We have a number of commands to set migration parameters (bandwidth, max downtime, etc). One thing that has always troubled me with this, is that they are a global setting for QEMU, not simply the next migration command. This is fine if you expect that only a single 'migrate' command will ever be invoked during the lifetime of QEMU, but this doesn't hold true when we use 'migrate' as a means to implement saving of snapshots/save-to-file, or "core" dumps. For example, when libvirt does 'save to file', we want to set the max bandwidth to unlimited for that, but we don't want that 'unlimited' setting to apply to a future cross-host migration attempt. This means we have to send three commands migrate_set_speed 9223372036854775808 migrate file:/some/file migrate_set_speed 33554432 it doubly sucks because there is no way to reset the migration speed to the QEMU default, so we have to hardcoded (32 << 20) which is what QEMU currently uses. It would be more desirable if we could simply pass in the desired speed, compression algorithm, max downtime, etc, as parameters to the 'migrate' command. And then have 'migrate_set_speed' only affect the current active migration, not any future ones. So a 'query-migration-caps' command is nice, but I think having a set-migration-caps command is wrong. There should just be a 'caps' parameter for 'migrate'. Regards, 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 :|