But right now, we trigged resize by flavor changed. Do you mean we can split the resize by cpu, by memory, or by disk? 在 2014-07-25 03:25:46，"Jesse Pretorius" <[email protected]> 写道： On 24 July 2014 20:38, Vishvananda Ishaya <[email protected]> wrote: The resize code as written originally did the simplest possible thing. It converts and copies the whole file so that it doesn’t have to figure out how to sync backing files etc. This could definitely be improved, especially now that there is code in _create_images_and_backing that can ensure that backing files are downloaded/created if they are not there. Additionally the resize code should be using something other than ssh/rsync. I’m a fan of using glance to store the file during transfer, but others have suggested using the live migrate code or libvirt to transfer the disks. 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.
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
