|Assignee:||Tino Vázquez||% Done:|
|Category:||Core & System|
|Target version:||Release 2.0|
The images for VM's disks are defined with the SOURCE attribute of the DISK template variable. This SOURCE is a URL, usually a file or a logical volume device, which is subsequently handled by the Transfer Manager. This generic approach has some drawbacks:
- The user has to define (and have to be aware of) the rest of the DISK attributes. For example the target device for the DISK.
- Files are handled by OpenNebula using the oneadmin identity. This makes difficult to enforce access policies for the images (e.g. define ACLs)
This campaign aims to develop an image repository for OpenNebula, description:
- The image repository will keep a logical mapping a high level description of an image disk and its physical location and configuration parameters. Example
"Ubuntu Karmic" --> /srv/cloud/images/ubuntu.img, file, sda1 "Windows Installation Disk" --> /srv/cloud/isos/winxp.iso, cdrom, hdb
- Each image can have an ACL defined. So OpenNebula can enforce access policies to a given image
- VM DISKS can be defined using the repository either by its description or using an ID, example:
NAME=my_vm CPU = 1 MEMORY = 128 DISK = [ IMAGE="Ubuntu Karmic" ] NIC = [ NETWORK="Public" ]
The DISK Attribute will be translated by OpenNebula to
DISK = [ SOURCE = "/srv/cloud/images/ubuntu.img", CLONE="yes", TARGET="sda1" ]
Users can override the repository values. Obviously, the use of the image repository is optional.
- The repository functionality will be exposed by the XML-RPC interface. A new CLI command
onestorageand OCA bindings will be developed.
feature #200: Insert, replace and remove methods for Image update the DB immediately.
feature #200: Image pool table definition changed to be compatible with both MySQL and Sqlite.
feature #200: Images can now modify a DISK attribute vector to include correct BUS and TARGET.
feature #200: New erase method for Template class: removes and frees attributes with the given name.
feature #200: New enable/publish methods, changed ImagePool interface for modifying template attributes.
feature #200: Integrates ImagePool and VirtualMachinePool. Now you can requests Images from VM templates!
feature #200: Images are set DISABLED upon creation (and not INIT). DISABLED names for oneimage
feature #200:Fix tests
Applied in wrong branch
Revert "feature #200 Added ImageManager for Image management in OCA"
This reverts commit c612987ada52530c13b1f70886cd55c0d1b53fa0.
feature #200: Get rid of Crack library for OCCI. OCCI now uses OpenNebula authorization mechanisms
#1 Updated by Gyula Csom over 10 years ago
In our environment we'd like to let users to upload their SSH keys, customization scripts, etc. generally speaking to upload any file they want to use in order to contextualize their VMs. My question are the following. Will the new image repository target end users, eg. exposed thru the OCCI interface too? Especially will the new functionality target the above use case or just cover images? Is their any plan in this regard?
Ps.: As far as I see there's nothing that would prevent users from uploading any file thru OCCI by using the image upload method already built into ONE. It could be an image or anything else they want. So technically speaking it seems that we can provide the above functionality (with the appropiate conventions and ERB templates). However it would be useful to provide some metadata support, too, eg. to let users to describe the files they uploaded.
#2 Updated by Ruben S. Montero over 10 years ago
Gyula Csom wrote:
My question are the following. Will the new image repository target end users, eg. exposed thru the OCCI interface too?
Yes our plan is to expose this through OCCI/EC2
Especially will the new functionality target the above use case or just cover images?
Initially we will target VM images
Is their any plan in this regard?
As a follow up development we will address this!
#4 Updated by Carlos Martín over 10 years ago
A quick comment on features that would be worth considering in next releases:
Right now, images contain the data and the necessary attributes to mount them as VM disks.
For OS type images, it would be nice to have also attributes for MEMORY, CPU, and BOOT sections of the VM template. This way, a user could decide to use an OS available in the repository with a simple template, like this one:
NAME = "My VM" OS_IMAGE = "Ubuntu desktop" DISK = "Accounts"
#5 Updated by Gyula Csom over 10 years ago
In our system (currently) we define similar metaadatas for (OS) images:
- SIZE (optional)
- OS_TYPE, OS_VERSION
so a sample image "template" might look like this:
PATH=iscsi://storage.sample.com/iqn.2010-07.com.sample:1111/0 SIZE="20 G" OS_TYPE=Ubuntu OS_VERSION=9 ARCHITECTURE=x86 DESC="Ubuntu server customized for webservers"
Now the user can choose the image by the various metadatas available and can link it to the VM template...