<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-11-27 19:49 GMT+08:00 Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.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">On Fri, Nov 27, 2015 at 07:37:50PM +0800, 少合冯 wrote:<br>
> <a href="tel:2015-11-27" value="+85220151127">2015-11-27</a> 2:19 GMT+08:00 Daniel P. Berrange <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>>:<br>
><br>
> > On Thu, Nov 26, 2015 at 05:39:04PM +0000, Daniel P. Berrange wrote:<br>
> > > On Thu, Nov 26, 2015 at 11:55:31PM +0800, 少合冯 wrote:<br>
> > > > 3.  dynamically choose when to activate xbzrle compress for live<br>
> > migration.<br>
> > > >      This is the best.<br>
> > > >      xbzrle really wants to be used if the network is not able to keep<br>
> > up<br>
> > > > with the dirtying rate of the guest RAM.<br>
> > > >      But how do I check the coming migration fit this situation？<br>
> > ><br>
> > > FWIW, if we decide we want compression support in Nova, I think that<br>
> > > having the Nova libvirt driver dynamically decide when to use it is<br>
> > > the only viable approach. Unfortunately the way the QEMU support<br>
> > > is implemented makes it very hard to use, as QEMU forces you to decide<br>
> > > to use it upfront, at a time when you don't have any useful information<br>
> > > on which to make the decision :-(  To be useful IMHO, we really need<br>
> > > the ability to turn on compression on the fly for an existing active<br>
> > > migration process. ie, we'd start migration off and let it run and<br>
> > > only enable compression if we encounter problems with completion.<br>
> > > Sadly we can't do this with QEMU as it stands today :-(<br>
> > ><br>
> ><br>
> [Shaohe Feng]<br>
> Add more guys working on kernel/hypervisor in our loop.<br>
> Wonder whether there will be any good solutions to improve it in QEMU in<br>
> future.<br>
><br></div></div></blockquote><div>IMHO,  It is possible to<span style="color:rgb(80,0,80)"> enable </span><span style="color:rgb(80,0,80)">XBZRLE </span><span style="color:rgb(80,0,80)"> </span><span style="color:rgb(80,0,80)">on the fly </span><span style="color:rgb(80,0,80)">during </span><span style="color:rgb(80,0,80)">for an existing active</span></div><div><span style="color:rgb(80,0,80)">migration process. </span><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)">Than need improvement in qemu. </span></div><div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)"> </span></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>
> > > Oh and of course we still need to address the issue of RAM usage and<br>
> > > communicating that need with the scheduler in order to avoid OOM<br>
> > > scenarios due to large compression cache.<br>
> > ><br>
> > > I tend to feel that the QEMU compression code is currently broken by<br>
> > > design and needs rework in QEMU before it can be pratically used in<br>
> > > an autonomous fashion :-(<br>
> ><br>
> > Actually thinking about it, there's not really any significant<br>
> > difference between Option 1 and Option 3. In both cases we want<br>
> > a nova.conf setting live_migration_compression=on|off to control<br>
> > whether we want to *permit* use  of compression.<br>
> ><br>
> > The only real difference between 1 & 3 is whether migration has<br>
> > compression enabled always, or whether we turn it on part way<br>
> > though migration.<br>
> ><br>
> > So although option 3 is our desired approach (which we can't<br>
> > actually implement due to QEMU limitations), option 1 could<br>
> > be made fairly similar if we start off with a very small<br>
> > compression cache size which would have the effect of more or<br>
> > less disabling compression initially.<br>
> ><br>
> > We already have logic in the code for dynamically increasing<br>
> > the max downtime value, which we could mirror here<br>
> ><br>
> > eg something like<br>
> ><br>
> >  live_migration_compression=on|off<br>
> ><br>
> >   - Whether to enable use of compression<br>
> ><br>
> >  live_migration_compression_cache_ratio=0.8<br>
> ><br>
> >   - The maximum size of the compression cache relative to<br>
> >     the guest RAM size. Must be less than 1.0<br>
> ><br>
> >  live_migration_compression_cache_steps=10<br>
> ><br>
> >   - The number of steps to take to get from initial cache<br>
> >     size to the maximum cache size<br>
> ><br>
> >  live_migration_compression_cache_delay=75<br>
> ><br>
> >   - The time delay in seconds between increases in cache<br>
> >     size<br>
> ><br>
> ><br>
> > In the same way that we do with migration downtime, instead of<br>
> > increasing cache size linearly, we'd increase it in ever larger<br>
> > steps until we hit the maximum. So we'd start off fairly small<br>
> > a few MB, and monitoring the cache hit rates, we'd increase it<br>
> > periodically.  If the number of steps configured and time delay<br>
> > between steps are reasonably large, that would have the effect<br>
> > that most migrations would have a fairly small cache and would<br>
> > complete without needing much compression overhead.<br>
> ><br>
> > Doing this though, we still need a solution to the host OOM scenario<br>
> > problem. We can't simply check free RAM at start of migration and<br>
> > see if there's enough to spare for compression cache, as the schedular<br>
> > can spawn a new guest on the compute host at any time, pushing us into<br>
> > OOM. We really need some way to indicate that there is a (potentially<br>
> > very large) extra RAM overhead for the guest during migration.<br>
> ><br>
> > ie if live_migration_compression_cache_ratio is 0.8 and we have a<br>
> > 4 GB guest, we need to make sure the schedular knows that we are<br>
> > potentially going to be using 7.2 GB of memory during migration<br>
> ><br>
> ><br>
> [Shaohe Feng]<br>
> These suggestions sounds good.<br>
> Thank you, Daneil.<br>
><br>
> Do we need to consider this factor:<br>
>   Seems, XBZRLE compress is executed after bulk stage. During the bulk<br>
> stage,<br>
>   calculate an transfer rate. If the transfer rate bellow a certain<br>
>   threshold value, we can set a bigger cache size.<br>
<br>
</div></div>I think it is probably sufficient to just look at the xbzrle cache<br>
hit rates every "live_migration_compression_cache_delay" seconds<br>
and decide how to tune the cache size based on that.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div>OK. agree, will update the spec.</div><div>Thank you.  </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>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a>      -o-    <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a>              -o-             <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a>       -o-         <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a>       -o-       <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</div></div></blockquote></div><br></div></div>