If you'd like to have a go at implementing this in nova's Juno release, then you need to create a new-style blueprint in the nova-specs repository. You can find more details about that process at https://wiki.openstack.org/wiki/Blueprints#Nova
Some initial thoughts though, some of which have already been brought up: - _some_ libvirt drivers already have image caching. I am unsure if all of them do, I'd have to check. - we already have blueprints for better support of glance multiple image locations, it might be better to extend that work than to do something completely separate. - the xen driver already does bittorrent image delivery IIRC, you could take a look at how that do that. - pre-caching images has been proposed for libvirt for a long time, but never implemented. I think that's definitely something of interest to deployers. Cheers, Michael On Wed, Apr 16, 2014 at 11:14 PM, yongquan Fu <quanyo...@gmail.com> wrote: > > Dear all, > > > > We would like to present an extension to the vm-booting functionality of > Nova when a number of homogeneous vms need to be launched at the same time. > > > > The motivation for our work is to increase the speed of provisioning vms for > large-scale scientific computing and big data processing. In that case, we > often need to boot tens and hundreds virtual machine instances at the same > time. > > > Currently, under the Openstack, we found that creating a large number of > virtual machine instances is very time-consuming. The reason is the booting > procedure is a centralized operation that involve performance bottlenecks. > Before a virtual machine can be actually started, OpenStack either copy the > image file (swift) or attach the image volume (cinder) from storage server > to compute node via network. Booting a single VM need to read a large amount > of image data from the image storage server. So creating a large number of > virtual machine instances would cause a significant workload on the servers. > The servers become quite busy even unavailable during the deployment phase. > It would consume a very long time before the whole virtual machine cluster > useable. > > > > Our extension is based on our work on vmThunder, a novel mechanism > accelerating the deployment of large number virtual machine instances. It is > written in Python, can be integrated with OpenStack easily. VMThunder > addresses the problem described above by following improvements: on-demand > transferring (network attached storage), compute node caching, P2P > transferring and prefetching. VMThunder is a scalable and cost-effective > accelerator for bulk provisioning of virtual machines. > > > > We hope to receive your feedbacks. Any comments are extremely welcome. > Thanks in advance. > > > > PS: > > > > VMThunder enhanced nova blueprint: > https://blueprints.launchpad.net/nova/+spec/thunderboost > > VMThunder standalone project: https://launchpad.net/vmthunder; > > VMThunder prototype: https://github.com/lihuiba/VMThunder > > VMThunder etherpad: https://etherpad.openstack.org/p/vmThunder > > VMThunder portal: http://www.vmthunder.org/ > > VMThunder paper: http://www.computer.org/csdl/trans/td/preprint/06719385.pdf > > > > Regards > > > > vmThunder development group > > PDL > > National University of Defense Technology > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Rackspace Australia _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
