<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><br><br><br><span style="line-height: 1.7;">But right now, we trigged resize by flavor changed. Do you mean we can split the resize by cpu, by memory, or by disk?</span><br><div></div><div id="divNeteaseMailCard"></div><br>ÔÚ 2014-07-25 03:25:46£¬"Jesse Pretorius" <jesse.pretorius@gmail.com> Ð´µÀ£º<br> <blockquote id="isReplyContent" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 July 2014 20:38, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The resize code as written originally did the simplest possible thing. It<br>
converts and copies the whole file so that it doesn¡¯t have to figure out how<br>
to sync backing files etc. This could definitely be improved, especially now that<br>
there is code in _create_images_and_backing that can ensure that backing files are<br>
downloaded/created if they are not there.<br>
<br>
Additionally the resize code should be using something other than ssh/rsync. I¡¯m<br>
a fan of using glance to store the file during transfer, but others have suggested<br>
using the live migrate code or libvirt to transfer the disks.<br></blockquote><div><br></div><div>I'd like to suggest an additional improvement - if the resize is only a CPU/Memory resize, then if the host can handle it the entire disk flattening/conversion/migration should be skipped and the resize of the CPU/Memory spec should be done in-place on the host. </div>
</div></div></div>
</blockquote></div>