Open Stack

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 <quanyongf at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia