On Fri, Apr 18, 2014 at 5:19 AM, Michael Still <mi...@stillhq.com> wrote: > 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. >
Thanks for clarification. > - 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. > Totally agreed. And I think currently seems there are two places (at least) could be leveraged: 1. Making this as an image download plug-ins for Nova, to be built-in or independent. I prefer to go this way, but need to make sure its context is enough for your case. 2. Making this as a built-in or independent image handler plug-ins, as a part of supporting of multiple-image-locations (on going) as Michael mentions here. zhiyan > - 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev