On Thu, Nov 26, 2015 at 05:49:50PM +0000, Paul Carlton wrote: > Seems to me the prevailing view is that we should get live migration to > figure out the best setting for > itself where possible. There was discussion of being able have a default > policy setting that will allow > the operator to define balance between speed of migration and impact on the > instance. This could be > a global default for the cloud with overriding defaults per aggregate, > image, tenant and instance as > well as the ability to vary the setting during the migration operation. > > Seems to me that items like compression should be set in configuration files > based on what works best > given the cloud operator's environment?
Merely turning on use of compression is the "easy" bit - there needs to be a way to deal with compression cache size allocation, which needs to have some smarts in Nova, as there's no usable "one size fits all" value for the compression cache size. If we did want to hardcode a compression cache size, you'd have to pick set it as a scaling factor against the guest RAM size. This is going to be very heavy on memory usage, so there needs careful design work to solve the problem of migration compression triggering host OOM scenarios, particularly since we can have multiple concurrent migrations. 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 :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
