2015-11-30 16:19 GMT+08:00 Koniszewski, Pawel <pawel.koniszew...@intel.com>:
> 2015-11-30 14:45 GMT+08:00 Koniszewski, Pawel <pawel.koniszew...@intel.com > >: > > -----Original Message----- > > From: Murray, Paul (HP Cloud) [mailto:pmur...@hpe.com] > > Sent: Friday, November 27, 2015 4:29 PM > > To: Daniel P. Berrange; Carlton, Paul (Cloud Services) > > Cc: 少合冯; OpenStack Development Mailing List (not for usage questions); > > John Garbutt; Koniszewski, Pawel; Jin, Yuntong; Feng, Shaohe; Qiao, > Liyong > > Subject: RE: [nova] [RFC] how to enable xbzrle compress for live > migration > > > > > > > > > -----Original Message----- > > > From: Daniel P. Berrange [mailto:berra...@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.koniszew...@intel.com; yuntong....@intel.com; > > > shaohe.f...@intel.com; Murray, Paul (HP Cloud); liyong.q...@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. > >I'd rather say that these resources might shrink. You need to turn off one > compute node, stack more VMs on remaining compute nodes and you need to > allocate cache on both sides, source and destination. > > >why do we need on destination? > > XBZRLE sends only a delta over network and it works in two phases: > compressing and decompressing. During compression the original page and > updated page are XORed together and resulting information is passed over to > the RLE algorithm - the output is the delta page which is sent over network > to destination host. During decompression run length decodes each pair of > symbol-counter and the original page is XORed with the result from the run > length decoding - the output is the updated page. It means that it needs to > allocate cache on source and destination node. > But I think the RAM on the destination is the original page . Just decompression with the delta. It does not need extra cache. > > 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. >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
