<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><pre><div><span style="white-space: normal;">>btw, I see but at the moment we had fixed it by network interface</span></div><div><span style="white-space: normal;">>device driver instead of workaround - to limit network traffic slow</span></div><div><span style="white-space: normal;">>down.</span></div><div><span style="white-space: normal;">Which kind of driver, in host kernel, in guest kernel or in openstack?</span></div><div><span style="white-space: normal;"><br></span></div><div><span style="white-space: normal;"><br></span></div><div><span style="white-space: normal;"><br></span></div><div><span style="white-space: normal;">>There are few works done in Glance</span></div><div><span style="white-space: normal;">>(https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver ),</span></div><div><span style="white-space: normal;">>but some work still need to be taken I'm sure. There are something on</span></div><div><span style="white-space: normal;">>drafting, and some dependencies need to be resolved as well.</span></div><div><span style="white-space: normal;">I read the blueprints carefully, but still have some doubts.</span></div><div><span style="white-space: normal;">Will it store an image as a single volume in cinder? Or store all image files</span></div><div><span style="white-space: normal;">in one shared volume (with a file system on the volume, of course)?</span></div><div><span style="white-space: normal;">Openstack </span><span style="white-space: normal; ">already </span><span style="white-space: normal; ">has support to convert an image to a volume, and to boot</span></div><div><span style="white-space: normal;">from a volume. Are these features similar to this blueprint?</span></div><div><span style="white-space: normal;"><br></span></div><div><span style="white-space: normal;"><br></span></div><div><span style="white-space: normal;">Huiba Li</span></div><div><span style="white-space: normal;"><br></span></div><div><span style="white-space: normal;">National Key Laboratory for Parallel and Distributed</span></div><div><span style="white-space: normal;">Processing, College of Computer Science, National University of Defense</span></div><div><span style="white-space: normal;">Technology, Changsha, Hunan Province, P.R. China</span></div><div><span style="white-space: normal;">410073</span></div><div><span style="white-space: normal;"><br></span></div><div><span style="white-space: normal;"><br></span></div><div><span style="white-space: normal;">At 2014-04-18 12:14:25,"Zhi Yan Liu" <lzy.dev@gmail.com> wrote:</span></div><div><span style="white-space: normal;">>On Fri, Apr 18, 2014 at 10:53 AM, lihuiba <magazine.lihuiba@163.com> wrote:</span></div><div><span style="white-space: normal;">>>>It's not 100% true, in my case at last. We fixed this problem by</span></div><div><span style="white-space: normal;">>>>network interface driver, it causes kernel panic and readonly issues</span></div><div><span style="white-space: normal;">>>>under heavy networking workload actually.</span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">>> Network traffic control could help. The point is to ensure no instance</span></div><div><span style="white-space: normal;">>> is starved to death. Traffic control can be done with tc.</span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">></span></div><div><span style="white-space: normal;">>btw, I see but at the moment we had fixed it by network interface</span></div><div><span style="white-space: normal;">>device driver instead of workaround - to limit network traffic slow</span></div><div><span style="white-space: normal;">>down.</span></div><div><span style="white-space: normal;">></span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">>>>btw, we are doing some works to make Glance to integrate Cinder as a</span></div><div><span style="white-space: normal;">>>>unified block storage</span></div><div><span style="white-space: normal;">>> backend.</span></div><div><span style="white-space: normal;">>> That sounds interesting. Is there some  more materials?</span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">></span></div><div><span style="white-space: normal;">>There are few works done in Glance</span></div><div><span style="white-space: normal;">>(https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver ),</span></div><div><span style="white-space: normal;">>but some work still need to be taken I'm sure. There are something on</span></div><div><span style="white-space: normal;">>drafting, and some dependencies need to be resolved as well.</span></div><div><span style="white-space: normal;">></span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">>> At 2014-04-18 06:05:23,"Zhi Yan Liu" <lzy.dev@gmail.com> wrote:</span></div><div><span style="white-space: normal;">>>>Replied as inline comments.</span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>On Thu, Apr 17, 2014 at 9:33 PM, lihuiba <magazine.lihuiba@163.com> wrote:</span></div><div><span style="white-space: normal;">>>>>>IMO we'd better to use backend storage optimized approach to access</span></div><div><span style="white-space: normal;">>>>>>remote image from compute node instead of using iSCSI only. And from</span></div><div><span style="white-space: normal;">>>>>>my experience, I'm sure iSCSI is short of stability under heavy I/O</span></div><div><span style="white-space: normal;">>>>>>workload in product environment, it could causes either VM filesystem</span></div><div><span style="white-space: normal;">>>>>>to be marked as readonly or VM kernel panic.</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> Yes, in this situation, the problem lies in the backend storage, so no</span></div><div><span style="white-space: normal;">>>>> other</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> protocol will perform better. However, P2P transferring will greatly</span></div><div><span style="white-space: normal;">>>>> reduce</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> workload on the backend storage, so as to increase responsiveness.</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>It's not 100% true, in my case at last. We fixed this problem by</span></div><div><span style="white-space: normal;">>>>network interface driver, it causes kernel panic and readonly issues</span></div><div><span style="white-space: normal;">>>>under heavy networking workload actually.</span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>>>As I said currently Nova already has image caching mechanism, so in</span></div><div><span style="white-space: normal;">>>>>>this case P2P is just an approach could be used for downloading or</span></div><div><span style="white-space: normal;">>>>>>preheating for image caching.</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> Nova's image caching is file level, while VMThunder's is block-level. And</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> VMThunder is for working in conjunction with Cinder, not Glance.</span></div><div><span style="white-space: normal;">>>>> VMThunder</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> currently uses facebook's flashcache to realize caching, and dm-cache,</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> bcache are also options in the future.</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>Hm if you say bcache, dm-cache and flashcache, I'm just thinking if</span></div><div><span style="white-space: normal;">>>>them could be leveraged by operation/best-practice level.</span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>btw, we are doing some works to make Glance to integrate Cinder as a</span></div><div><span style="white-space: normal;">>>>unified block storage backend.</span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>>>I think  P2P transferring/pre-caching sounds a  good way to go, as I</span></div><div><span style="white-space: normal;">>>>>>mentioned as well, but actually for the area I'd like to see something</span></div><div><span style="white-space: normal;">>>>>>like zero-copy + CoR. On one hand we can leverage the capability of</span></div><div><span style="white-space: normal;">>>>>>on-demand downloading image bits by zero-copy approach, on the other</span></div><div><span style="white-space: normal;">>>>>>hand we can prevent to reading data from remote image every time by</span></div><div><span style="white-space: normal;">>>>>>CoR.</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> Yes, on-demand transferring is what you mean by "zero-copy", and caching</span></div><div><span style="white-space: normal;">>>>> is something close to CoR. In fact, we are working on a kernel module</span></div><div><span style="white-space: normal;">>>>> called</span></div><div><span style="white-space: normal;">>>>> foolcache that realize a true CoR. See</span></div><div><span style="white-space: normal;">>>>> https://github.com/lihuiba/dm-foolcache.</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>Yup. And it's really interesting to me, will take a look, thanks for</span></div><div><span style="white-space: normal;">>>> sharing.</span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> National Key Laboratory for Parallel and Distributed</span></div><div><span style="white-space: normal;">>>>> Processing, College of Computer Science, National University of Defense</span></div><div><span style="white-space: normal;">>>>> Technology, Changsha, Hunan Province, P.R. China</span></div><div><span style="white-space: normal;">>>>> 410073</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> At 2014-04-17 17:11:48,"Zhi Yan Liu" <lzy.dev@gmail.com> wrote:</span></div><div><span style="white-space: normal;">>>>>>On Thu, Apr 17, 2014 at 4:41 PM, lihuiba <magazine.lihuiba@163.com></span></div><div><span style="white-space: normal;">>>>>> wrote:</span></div><div><span style="white-space: normal;">>>>>>>>IMHO, zero-copy approach is better</span></div><div><span style="white-space: normal;">>>>>>> VMThunder's "on-demand transferring" is the same thing as your</span></div><div><span style="white-space: normal;">>>>>>> "zero-copy</span></div><div><span style="white-space: normal;">>>>>>> approach".</span></div><div><span style="white-space: normal;">>>>>>> VMThunder is uses iSCSI as the transferring protocol, which is option</span></div><div><span style="white-space: normal;">>>>>>> #b</span></div><div><span style="white-space: normal;">>>>>>> of</span></div><div><span style="white-space: normal;">>>>>>> yours.</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>></span></div><div><span style="white-space: normal;">>>>>>IMO we'd better to use backend storage optimized approach to access</span></div><div><span style="white-space: normal;">>>>>>remote image from compute node instead of using iSCSI only. And from</span></div><div><span style="white-space: normal;">>>>>>my experience, I'm sure iSCSI is short of stability under heavy I/O</span></div><div><span style="white-space: normal;">>>>>>workload in product environment, it could causes either VM filesystem</span></div><div><span style="white-space: normal;">>>>>>to be marked as readonly or VM kernel panic.</span></div><div><span style="white-space: normal;">>>>>></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>Under #b approach, my former experience from our previous similar</span></div><div><span style="white-space: normal;">>>>>>>>Cloud deployment (not OpenStack) was that: under 2 PC server storage</span></div><div><span style="white-space: normal;">>>>>>>>nodes (general *local SAS disk*, without any storage backend) +</span></div><div><span style="white-space: normal;">>>>>>>>2-way/multi-path iSCSI + 1G network bandwidth, we can provisioning 500</span></div><div><span style="white-space: normal;">>>>>>>>VMs in a minute.</span></div><div><span style="white-space: normal;">>>>>>> suppose booting one instance requires reading 300MB of data, so 500</span></div><div><span style="white-space: normal;">>>>>>> ones</span></div><div><span style="white-space: normal;">>>>>>> require 150GB.  Each of the storage server needs to send data at a rate</span></div><div><span style="white-space: normal;">>>>>>> of</span></div><div><span style="white-space: normal;">>>>>>> 150GB/2/60 = 1.25GB/s on average. This is absolutely a heavy burden</span></div><div><span style="white-space: normal;">>>>>>> even</span></div><div><span style="white-space: normal;">>>>>>> for high-end storage appliances. In production  systems, this request</span></div><div><span style="white-space: normal;">>>>>>> (booting</span></div><div><span style="white-space: normal;">>>>>>> 500 VMs in one shot) will significantly disturb  other running</span></div><div><span style="white-space: normal;">>>>>>> instances</span></div><div><span style="white-space: normal;">>>>>>> accessing the same storage nodes.</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>btw, I believe the case/numbers is not true as well, since remote</span></div><div><span style="white-space: normal;">>>>image bits could be loaded on-demand instead of load them all on boot</span></div><div><span style="white-space: normal;">>>>stage.</span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>zhiyan</span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>>>> VMThunder eliminates this problem by P2P transferring and</span></div><div><span style="white-space: normal;">>>>>>> on-compute-node</span></div><div><span style="white-space: normal;">>>>>>> caching. Even a pc server with one 1gb NIC (this is a true pc server!)</span></div><div><span style="white-space: normal;">>>>>>> can</span></div><div><span style="white-space: normal;">>>>>>> boot</span></div><div><span style="white-space: normal;">>>>>>> 500 VMs in a minute with ease. For the first time, VMThunder makes bulk</span></div><div><span style="white-space: normal;">>>>>>> provisioning of VMs practical for production cloud systems. This is the</span></div><div><span style="white-space: normal;">>>>>>> essential</span></div><div><span style="white-space: normal;">>>>>>> value of VMThunder.</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>></span></div><div><span style="white-space: normal;">>>>>>As I said currently Nova already has image caching mechanism, so in</span></div><div><span style="white-space: normal;">>>>>>this case P2P is just an approach could be used for downloading or</span></div><div><span style="white-space: normal;">>>>>>preheating for image caching.</span></div><div><span style="white-space: normal;">>>>>></span></div><div><span style="white-space: normal;">>>>>>I think  P2P transferring/pre-caching sounds a  good way to go, as I</span></div><div><span style="white-space: normal;">>>>>>mentioned as well, but actually for the area I'd like to see something</span></div><div><span style="white-space: normal;">>>>>>like zero-copy + CoR. On one hand we can leverage the capability of</span></div><div><span style="white-space: normal;">>>>>>on-demand downloading image bits by zero-copy approach, on the other</span></div><div><span style="white-space: normal;">>>>>>hand we can prevent to reading data from remote image every time by</span></div><div><span style="white-space: normal;">>>>>>CoR.</span></div><div><span style="white-space: normal;">>>>>></span></div><div><span style="white-space: normal;">>>>>>zhiyan</span></div><div><span style="white-space: normal;">>>>>></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> ===================================================</span></div><div><span style="white-space: normal;">>>>>>> From: Zhi Yan Liu <lzy.dev@gmail.com></span></div><div><span style="white-space: normal;">>>>>>> Date: 2014-04-17 0:02 GMT+08:00</span></div><div><span style="white-space: normal;">>>>>>> Subject: Re: [openstack-dev] [Nova][blueprint] Accelerate the booting</span></div><div><span style="white-space: normal;">>>>>>> process of a number of vms via VMThunder</span></div><div><span style="white-space: normal;">>>>>>> To: "OpenStack Development Mailing List (not for usage questions)"</span></div><div><span style="white-space: normal;">>>>>>> <openstack-dev@lists.openstack.org></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> Hello Yongquan Fu,</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> My thoughts:</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> 1. Currently Nova has already supported image caching mechanism. It</span></div><div><span style="white-space: normal;">>>>>>> could caches the image on compute host which VM had provisioning from</span></div><div><span style="white-space: normal;">>>>>>> it before, and next provisioning (boot same image) doesn't need to</span></div><div><span style="white-space: normal;">>>>>>> transfer it again only if cache-manger clear it up.</span></div><div><span style="white-space: normal;">>>>>>> 2. P2P transferring and prefacing is something that still based on</span></div><div><span style="white-space: normal;">>>>>>> copy mechanism, IMHO, zero-copy approach is better, even</span></div><div><span style="white-space: normal;">>>>>>> transferring/prefacing could be optimized by such approach. (I have</span></div><div><span style="white-space: normal;">>>>>>> not check "on-demand transferring" of VMThunder, but it is a kind of</span></div><div><span style="white-space: normal;">>>>>>> transferring as well, at last from its literal meaning).</span></div><div><span style="white-space: normal;">>>>>>> And btw, IMO, we have two ways can go follow zero-copy idea:</span></div><div><span style="white-space: normal;">>>>>>> a. when Nova and Glance use same backend storage, we could use storage</span></div><div><span style="white-space: normal;">>>>>>> special CoW/snapshot approach to prepare VM disk instead of</span></div><div><span style="white-space: normal;">>>>>>> copy/transferring image bits (through HTTP/network or local copy).</span></div><div><span style="white-space: normal;">>>>>>> b. without "unified" storage, we could attach volume/LUN to compute</span></div><div><span style="white-space: normal;">>>>>>> node from backend storage as a base image, then do such CoW/snapshot</span></div><div><span style="white-space: normal;">>>>>>> on it to prepare root/ephemeral disk of VM. This way just like</span></div><div><span style="white-space: normal;">>>>>>> boot-from-volume but different is that we do CoW/snapshot on Nova side</span></div><div><span style="white-space: normal;">>>>>>> instead of Cinder/storage side.</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> For option #a, we have already got some progress:</span></div><div><span style="white-space: normal;">>>>>>> https://blueprints.launchpad.net/nova/+spec/image-multiple-location</span></div><div><span style="white-space: normal;">>>>>>> https://blueprints.launchpad.net/nova/+spec/rbd-clone-image-handler</span></div><div><span style="white-space: normal;">>>>>>> https://blueprints.launchpad.net/nova/+spec/vmware-clone-image-handler</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> Under #b approach, my former experience from our previous similar</span></div><div><span style="white-space: normal;">>>>>>> Cloud deployment (not OpenStack) was that: under 2 PC server storage</span></div><div><span style="white-space: normal;">>>>>>> nodes (general *local SAS disk*, without any storage backend) +</span></div><div><span style="white-space: normal;">>>>>>> 2-way/multi-path iSCSI + 1G network bandwidth, we can provisioning 500</span></div><div><span style="white-space: normal;">>>>>>> VMs in a minute.</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> For vmThunder topic I think it sounds a good idea, IMO P2P, prefacing</span></div><div><span style="white-space: normal;">>>>>>> is one of optimized approach for image transferring valuably.</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> zhiyan</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> On Wed, Apr 16, 2014 at 9:14 PM, yongquan Fu <quanyongf@gmail.com></span></div><div><span style="white-space: normal;">>>>>>> wrote:</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>> Dear all,</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>  We would like to present an extension to the vm-booting functionality</span></div><div><span style="white-space: normal;">>>>>>>> of</span></div><div><span style="white-space: normal;">>>>>>>> Nova when a number of homogeneous vms need to be launched at the same</span></div><div><span style="white-space: normal;">>>>>>>> time.</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>> The motivation for our work is to increase the speed of provisioning</span></div><div><span style="white-space: normal;">>>>>>>> vms</span></div><div><span style="white-space: normal;">>>>>>>> for</span></div><div><span style="white-space: normal;">>>>>>>> large-scale scientific computing and big data processing. In that</span></div><div><span style="white-space: normal;">>>>>>>> case,</span></div><div><span style="white-space: normal;">>>>>>>> we</span></div><div><span style="white-space: normal;">>>>>>>> often need to boot tens and hundreds virtual machine instances at the</span></div><div><span style="white-space: normal;">>>>>>>> same</span></div><div><span style="white-space: normal;">>>>>>>> time.</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>     Currently, under the Openstack, we found that creating a large</span></div><div><span style="white-space: normal;">>>>>>>> number</span></div><div><span style="white-space: normal;">>>>>>>> of</span></div><div><span style="white-space: normal;">>>>>>>> virtual machine instances is very time-consuming. The reason is the</span></div><div><span style="white-space: normal;">>>>>>>> booting</span></div><div><span style="white-space: normal;">>>>>>>> procedure is a centralized operation that involve performance</span></div><div><span style="white-space: normal;">>>>>>>> bottlenecks.</span></div><div><span style="white-space: normal;">>>>>>>> Before a virtual machine can be actually started, OpenStack either</span></div><div><span style="white-space: normal;">>>>>>>> copy</span></div><div><span style="white-space: normal;">>>>>>>> the</span></div><div><span style="white-space: normal;">>>>>>>> image file (swift) or attach the image volume (cinder) from storage</span></div><div><span style="white-space: normal;">>>>>>>> server</span></div><div><span style="white-space: normal;">>>>>>>> to compute node via network. Booting a single VM need to read a large</span></div><div><span style="white-space: normal;">>>>>>>> amount</span></div><div><span style="white-space: normal;">>>>>>>> of image data from the image storage server. So creating a large</span></div><div><span style="white-space: normal;">>>>>>>> number</span></div><div><span style="white-space: normal;">>>>>>>> of</span></div><div><span style="white-space: normal;">>>>>>>> virtual machine instances would cause a significant workload on the</span></div><div><span style="white-space: normal;">>>>>>>> servers.</span></div><div><span style="white-space: normal;">>>>>>>> The servers become quite busy even unavailable during the deployment</span></div><div><span style="white-space: normal;">>>>>>>> phase.</span></div><div><span style="white-space: normal;">>>>>>>> It would consume a very long time before the whole virtual machine</span></div><div><span style="white-space: normal;">>>>>>>> cluster</span></div><div><span style="white-space: normal;">>>>>>>> useable.</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>   Our extension is based on our work on vmThunder, a novel mechanism</span></div><div><span style="white-space: normal;">>>>>>>> accelerating the deployment of large number virtual machine instances.</span></div><div><span style="white-space: normal;">>>>>>>> It</span></div><div><span style="white-space: normal;">>>>>>>> is</span></div><div><span style="white-space: normal;">>>>>>>> written in Python, can be integrated with OpenStack easily. VMThunder</span></div><div><span style="white-space: normal;">>>>>>>> addresses the problem described above by following improvements:</span></div><div><span style="white-space: normal;">>>>>>>> on-demand</span></div><div><span style="white-space: normal;">>>>>>>> transferring (network attached storage), compute node caching, P2P</span></div><div><span style="white-space: normal;">>>>>>>> transferring and prefetching. VMThunder is a scalable and</span></div><div><span style="white-space: normal;">>>>>>>> cost-effective</span></div><div><span style="white-space: normal;">>>>>>>> accelerator for bulk provisioning of virtual machines.</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>   We hope to receive your feedbacks. Any comments are extremely</span></div><div><span style="white-space: normal;">>>>>>>> welcome.</span></div><div><span style="white-space: normal;">>>>>>>> Thanks in advance.</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>> PS:</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>> VMThunder enhanced nova blueprint:</span></div><div><span style="white-space: normal;">>>>>>>> https://blueprints.launchpad.net/nova/+spec/thunderboost</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>  VMThunder standalone project: https://launchpad.net/vmthunder;</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>  VMThunder prototype: https://github.com/lihuiba/VMThunder</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>  VMThunder etherpad: https://etherpad.openstack.org/p/vmThunder</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>  VMThunder portal: http://www.vmthunder.org/</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>> VMThunder paper:</span></div><div><span style="white-space: normal;">>>>>>>> http://www.computer.org/csdl/trans/td/preprint/06719385.pdf</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>   Regards</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>   vmThunder development group</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>   PDL</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>>   National University of Defense Technology</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>>> _______________________________________________</span></div><div><span style="white-space: normal;">>>>>>>> OpenStack-dev mailing list</span></div><div><span style="white-space: normal;">>>>>>>> OpenStack-dev@lists.openstack.org</span></div><div><span style="white-space: normal;">>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></div><div><span style="white-space: normal;">>>>>>>></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> _______________________________________________</span></div><div><span style="white-space: normal;">>>>>>> OpenStack-dev mailing list</span></div><div><span style="white-space: normal;">>>>>>> OpenStack-dev@lists.openstack.org</span></div><div><span style="white-space: normal;">>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> --</span></div><div><span style="white-space: normal;">>>>>>> Yongquan Fu</span></div><div><span style="white-space: normal;">>>>>>> PhD, Assistant Professor,</span></div><div><span style="white-space: normal;">>>>>>> National Key Laboratory for Parallel and Distributed</span></div><div><span style="white-space: normal;">>>>>>> Processing, College of Computer Science, National University of Defense</span></div><div><span style="white-space: normal;">>>>>>> Technology, Changsha, Hunan Province, P.R. China</span></div><div><span style="white-space: normal;">>>>>>> 410073</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>>> _______________________________________________</span></div><div><span style="white-space: normal;">>>>>>> OpenStack-dev mailing list</span></div><div><span style="white-space: normal;">>>>>>> OpenStack-dev@lists.openstack.org</span></div><div><span style="white-space: normal;">>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></div><div><span style="white-space: normal;">>>>>>></span></div><div><span style="white-space: normal;">>>>>></span></div><div><span style="white-space: normal;">>>>>>_______________________________________________</span></div><div><span style="white-space: normal;">>>>>>OpenStack-dev mailing list</span></div><div><span style="white-space: normal;">>>>>>OpenStack-dev@lists.openstack.org</span></div><div><span style="white-space: normal;">>>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>>> _______________________________________________</span></div><div><span style="white-space: normal;">>>>> OpenStack-dev mailing list</span></div><div><span style="white-space: normal;">>>>> OpenStack-dev@lists.openstack.org</span></div><div><span style="white-space: normal;">>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></div><div><span style="white-space: normal;">>>>></span></div><div><span style="white-space: normal;">>>></span></div><div><span style="white-space: normal;">>>>_______________________________________________</span></div><div><span style="white-space: normal;">>>>OpenStack-dev mailing list</span></div><div><span style="white-space: normal;">>>>OpenStack-dev@lists.openstack.org</span></div><div><span style="white-space: normal;">>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">>> _______________________________________________</span></div><div><span style="white-space: normal;">>> OpenStack-dev mailing list</span></div><div><span style="white-space: normal;">>> OpenStack-dev@lists.openstack.org</span></div><div><span style="white-space: normal;">>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></div><div><span style="white-space: normal;">>></span></div><div><span style="white-space: normal;">></span></div><div><span style="white-space: normal;">>_______________________________________________</span></div><div><span style="white-space: normal;">>OpenStack-dev mailing list</span></div><div><span style="white-space: normal;">>OpenStack-dev@lists.openstack.org</span></div><div><span style="white-space: normal;">>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></div></pre></div>