Open Stack

> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: 26 November 2015 17:58
> To: Carlton, Paul (Cloud Services)
> Cc: 少合冯; OpenStack Development Mailing List (not for usage questions);
> John Garbutt; pawel.koniszewski at intel.com; yuntong.jin at intel.com;
> shaohe.feng at intel.com; Murray, Paul (HP Cloud); liyong.qiao at intel.com
> Subject: Re: [nova] [RFC] how to enable xbzrle compress for live migration
> 
> 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.
> 


Use cases for live migration generally fall into two types:

1. I need to empty the host (host maintenance/reboot)

2. I generally want to balance load on the cloud

The first case is by far the most common need right now and in that case the node gets progressively more empty as VMs are moved off. So the resources available for caching etc. grow as the process goes on.

The second case is less likely to be urgent from the operators point of view, so doing things more slowly may not be a problem.

So looking at how much resource is available at the start of a migration and deciding then what to do on a per VM basis is probably not a bad idea. Especially if we can differentiate between the two cases.


> 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 :|