https://github.com/gambol99/opennebula
Opennebula
https://github.com/gambol99/opennebula
Last synced: 4 months ago
JSON representation
Opennebula
- Host: GitHub
- URL: https://github.com/gambol99/opennebula
- Owner: gambol99
- Created: 2014-01-25T18:21:41.000Z (over 11 years ago)
- Default Branch: master
- Last Pushed: 2014-01-26T12:47:19.000Z (over 11 years ago)
- Last Synced: 2024-12-31T21:32:04.484Z (6 months ago)
- Size: 156 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README
Awesome Lists containing this project
README
============
Opennebula
============
Contains a number of scripts / changes for a Opennebula deployed
preload.rb
===========
The default tm_ssh transport manager uses a scp from controller to compute node - while the method is fine, it was SLOW, copying gigabytes across the network. The first method used to improve the performance was a local cached copy of the of the images from the controller. A simple rscync of the datastore was pushed by puppet on each of the compute nodes (/var/lib/one/cached). The tm_ssh ln / clone (/var/lib/one/remotes/tmm/tm_ssh/{clone,ln}) scripts were then changed to call preload.rb, taking the image name and performing the cp /var/lib/one/datastore/0 etc .. The method once again was fine, but it still took 5/10 seconds to perform the copy (natually dependent on the underlining storage system). So the next step we a preload of the images i.e. image-name.{0..10} and use a mv image. rather than copy.
The preload.rb performs the above - it has two functions; preload and clone. The preloading looks at the local cached copies of the images and makes x copies for clone to use. The clone takes the image name, looks for a matching preloaded image and moves it to the destination. Preloading uses a single atomic lock, which clone uses a flock per preload image. Note, the clone can also resizes the image if requested
occi_templates
==============
Contains some of the occi templates we were using for production boxes; I needed the ability to control cluster id and placement (i.e. which kvm to place upon) by hidden it on the CONTEXT section (take a look at common.erb)