<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-11-30 16:19 GMT+08:00 Koniszewski, Pawel <span dir="ltr"><<a href="mailto:pawel.koniszewski@intel.com" target="_blank">pawel.koniszewski@intel.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">2015-11-30 14:45 GMT+08:00 Koniszewski, Pawel <<a href="mailto:pawel.koniszewski@intel.com">pawel.koniszewski@intel.com</a>>:<br>
> -----Original Message-----<br>
> From: Murray, Paul (HP Cloud) [mailto:<a href="mailto:pmurray@hpe.com">pmurray@hpe.com</a>]<br>
> Sent: Friday, November 27, 2015 4:29 PM<br>
> To: Daniel P. Berrange; Carlton, Paul (Cloud Services)<br>
> Cc: 少合冯; OpenStack Development Mailing List (not for usage questions);<br>
> John Garbutt; Koniszewski, Pawel; Jin, Yuntong; Feng, Shaohe; Qiao, Liyong<br>
> Subject: RE: [nova] [RFC] how to enable xbzrle compress for live migration<br>
><br>
><br>
><br>
> > -----Original Message-----<br>
> > From: Daniel P. Berrange [mailto:<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>]<br>
> > Sent: 26 November 2015 17:58<br>
> > To: Carlton, Paul (Cloud Services)<br>
> > Cc: 少合冯; OpenStack Development Mailing List (not for usage<br>
> questions);<br>
> > John Garbutt; <a href="mailto:pawel.koniszewski@intel.com">pawel.koniszewski@intel.com</a>; <a href="mailto:yuntong.jin@intel.com">yuntong.jin@intel.com</a>;<br>
> > <a href="mailto:shaohe.feng@intel.com">shaohe.feng@intel.com</a>; Murray, Paul (HP Cloud); <a href="mailto:liyong.qiao@intel.com">liyong.qiao@intel.com</a><br>
> > Subject: Re: [nova] [RFC] how to enable xbzrle compress for live<br>
> > migration<br>
> ><br>
> > On Thu, Nov 26, 2015 at 05:49:50PM +0000, Paul Carlton wrote:<br>
> > > Seems to me the prevailing view is that we should get live migration<br>
> > > to figure out the best setting for itself where possible.  There was<br>
> > > discussion of being able have a default policy setting that will<br>
> > > allow the operator to define balance between speed of migration and<br>
> > > impact on the instance.  This could be a global default for the<br>
> > > cloud with overriding defaults per aggregate, image, tenant and<br>
> > > instance as well as the ability to vary the setting during the<br>
migration<br>
> operation.<br>
> > ><br>
> > > Seems to me that items like compression should be set in<br>
> > > configuration files based on what works best given the cloud<br>
operator's<br>
> environment?<br>
> ><br>
> > Merely turning on use of compression is the "easy" bit - there needs<br>
> > to be a way to deal with compression cache size allocation, which<br>
> > needs to have some smarts in Nova, as there's no usable "one size fits<br>
> > all" value for the compression cache size. If we did want to hardcode<br>
> > a compression cache size, you'd have to pick set it as a scaling factor<br>
against<br>
> the guest RAM size.<br>
> > This is going to be very heavy on memory usage, so there needs careful<br>
> > design work to solve the problem of migration compression triggering<br>
> > host OOM scenarios, particularly since we can have multiple concurrent<br>
> > migrations.<br>
> ><br>
><br>
><br>
> Use cases for live migration generally fall into two types:<br>
><br>
> 1. I need to empty the host (host maintenance/reboot)<br>
><br>
> 2. I generally want to balance load on the cloud<br>
><br>
> The first case is by far the most common need right now and in that case<br>
the<br>
> node gets progressively more empty as VMs are moved off. So the resources<br>
> available for caching etc. grow as the process goes on.<br>
>I'd rather say that these resources might shrink. You need to turn off one<br>
compute node, stack more VMs on remaining compute nodes and you need to<br>
allocate cache on both sides, source and destination.<br>
<br>
>why do we need on destination?<br>
<br>
</div></div>XBZRLE sends only a delta over network and it works in two phases:<br>
compressing and decompressing. During compression the original page and<br>
updated page are XORed together and resulting information is passed over to<br>
the RLE algorithm - the output is the delta page which is sent over network<br>
to destination host. During decompression run length decodes each pair of<br>
symbol-counter and the original page is XORed with the result from the run<br>
length decoding - the output is the updated page. It means that it needs to<br>
allocate cache on source and destination node.<br></blockquote><div><br></div><div>But I think the RAM on the destination is the  original  page . Just decompression </div><div>with the delta.</div><div><br></div><div>It does not need extra cache.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
> The second case is less likely to be urgent from the operators point of<br>
view,<br>
> so doing things more slowly may not be a problem.<br>
><br>
> So looking at how much resource is available at the start of a migration<br>
and<br>
> deciding then what to do on a per VM basis is probably not a bad idea.<br>
> Especially if we can differentiate between the two cases.<br>
</div></div></blockquote></div><br></div></div>