Hi Steven,
This is an interesting use-case. When we designed the image repository, we
had to make a compromise between expectable behaviour and advanced
customization usage. I guess this falls into the advanced usage, but
OpenNebula is flexible enough to take this challenge.
To automatically save all VM disks that use a certain Image, you can use
hooks.
I would add a new flag to all the relevant images in your system, either
having them in the image template, or adding them afterwards [1]:
oneimage addattr image_id AUTO_SAVE YES
This will add the flag to the template:
$ oneimage show 1
IMAGE INFORMATION
[...]
IMAGE TEMPLATE
*AUTO_SAVE=YES*
DEV_PREFIX=hd
NAME=test_image
PATH=/home/cmartin/trabajo/scratch/steven/disk.img
TYPE=OS
To add a new hook to the system, edit $ONE_LOCATION/etc/oned.conf [2] and
add something similar to the following:
VM_HOOK = [
name = auto_save,
on= CREATE,
command = auto_save.rb,
arguments = $VMID ]
This will execute a new script, placed in
$ONE_LOCATION/share/hooks/auto_save.rb, every time a new VM is created.
I suggest you to use ruby, because the ruby OCA API [3] will make it easier.
This script will have to:
1) Get the complete information for VM vm_id from OpenNebula.
2) For each disk, check if it is using an Image.
2.1) Get that image's information, and look for the AUTO_SAVE=YES attribute.
If it's present, then issue a onevm saveas operation over that vm-id and
disk-id.
To be able to identify the disks later, you could include in the new image
name the vm-id_disk-id string.
This way, files will be all managed by OpenNebula in the repository. If you
are doing this for back-up purposes, and you won't actually instantiate a VM
using this saved images, you can always move that files away from the
repository and then delete the images.
This is the easiest and elegant way I see to do this, but any
other opinions are welcome.
I'd also like to ask the community if more people feel this should be
supported out of the box by OpenNebula. If so, we could start a discussion
to determine the specific features or requirements this would imply.
Best regards,
Carlos.
[1] http://opennebula.org/doc/2.0/cli/oneimage.html
[2] http://opennebula.org/documentation:rel2.0:oned_conf#hook_system
[3] http://opennebula.org/documentation:rel2.0:ruby
Carlos Martín, Cloud Technology Engineer/Researcher
DSA Research Group: web http://dsa-research.org and blog
http://blog.dsa-research.org
OpenNebula Open Source Toolkit for Cloud Computing:
http://www.OpenNebula.org
On 30 November 2010 21:56, Steven Timm t...@fnal.gov wrote:
In
http://www.opennebula.org/documentation:rel2.0:img_guide
it says
When images are published they are always cloned, and persistent images
are never cloned. Therefore, an image cannot be public and persistent at the
same time. To manage a public image that won't be cloned, unpublish it first
and make it persistent.
I have stored a 10GB OS image in the repository
and made it public
-bash-3.2$ oneimage show 8
IMAGE INFORMATION
ID : 8
NAME : new-2.6.18-194.26.1.img
TYPE : OS
REGISTER TIME : 11/29 14:15:13
PUBLIC : Yes
PERSISTENT : No
SOURCE :
/var/lib/one/image-repo/920301ec2fcc29f9c621c3ebe2a8f5ac6b27fca6
STATE : used
RUNNING_VMS: 2
IMAGE TEMPLATE
DEV_PREFIX=vd
NAME=new-2.6.18-194.26.1.img
-bash-3.2$
I would like to have this available as a template image for
many users to be able to use.
I have successfully been able to have 2 users
use it as part of a VM with the following syntax
DISK = [ image = new-2.6.18-194.26.1.img ]
However, I find that this automatically implies a
SAVE=NO once the VM is launched, with no way to override it.
From output of onevm show:
DISK=[
CLONE=YES,
DISK_ID=0,
IMAGE=new-2.6.18-194.26.1.img,
IMAGE_ID=8,
READONLY=NO,
SAVE=NO,
SOURCE=/var/lib/one/image-repo/920301ec2fcc29f9c621c3ebe2a8f5ac6b27fca6,
TARGET=vda,
TYPE=DISK ]
-
So is there any way to do the following:
1) have the VM registered in the repository for all to see
2) be launched public and cloned on launch so it can be used
in multiple VM's at once
3) have the result be saved in an image-specific file when
each VM is shut down, and not back to the repository?
***I know that if I execute the onevm saveas command I can
get this done on a machine-by-machine basis but would
prefer a way to make it automatic.
-
The second question is closely related, namely:
Once a public image is declared in the database, is there any way
to actually update the content of that image, such that for instance
Name = latest kernel template image
could be periodically updated with the latest kernel
and all new VM's would pick it up?
Thanks
Steve Timm
