On 04/18/11 10:55, Jaime Melis wrote:
Hi Viven,
The use of different TM mechanism is quite interesting, as you propose
probably the best way to handle this is a TM clever enough to choose
the corresponding storage backend for different disks. In fact, that
is the spirit of the example at [1], although simplier than the one
you propose.
I've seen this example, but I didn't find it quite flexible enough.
* Include the TM options in the Image template. Define an
image "Debian base system", with the proper TM options to handle it.
The TM_OPTIONS will be stored in the image definition and could be
accessed trough the driver by getting the VM id from the SRC_PATH and
from there 'onevm show <id>', and get the disk that match de disk_id
(also from the SRC_PATH, note that disks are named disk.<disk_id>) to
get the IMAGE and the TM options from 'oneimage show'.
* Use special URLs for your images so the TM knows how to handle them.
For example, iscsi_filer://debian. URLs are not modified by OpenNebula
so you get the that URL. In the TM you can have the TM options for
different URLs
In my opinion, URLs are meant as a way of finding things (like in that
example), not as a way to know where to put them. Given a line like :
CLONE http:///srv/cloud/images/debian.img
192.168.0.74:/var/lib/one//26/images/disk.0
I have no simple way to know if /var/lib/one//26/images/disk.0 should
point to iscsi or nfs storage.
Of course I could specify something like
http:///srv/cloud/images/debian.img@iscsi/filer1/target1/, but I would
need to create images for http:///srv/cloud/images/debian.img@local/,
http:///srv/cloud/images/debian.img@iscsi/filer2/target34/, or
http:///srv/cloud/images/debian.img@nfs/filer1/path/to/share/.
I find such a hack unnecessarily complex, and very counter-intuitive.
NOTE: There is a "bug" in 2.2 that removes the custom attributes (like
TM_OPTIONS you propose) [2]. This will be solved in 2.4. Storing the
TM_OPTIONS have some advantages as you do not have to include them in
all the templates that uses that OPTIONS. Also, if you want to change
them you only have to do it in the Image Pool.
This is odd, my testing shows (on 2.2) that custom attributes for a disk
are actually kept. They are shown when I do a "onevm show" (although the
quotes are removed):
DISK=[
CLONE=NO,
DISK_ID=0,
READONLY=no,
SOURCE=/srv/cloud/images/debian.img,
TARGET=sda1,
TM_OPTIONS=--foo=bar --bar=baz ]
So it would be possible to write a "very smart" TM that would :
- the VM ID from $SRC_PATH
- get the disk ID from $DST_PATH
- parse the output of onevm show, and extract the value of TM_OPTIONS.
- if no options are found, parse output of oneimage show.
However, this is complex, and therefore error prone and hard to maintain.
I think that this approach is pretty close to the Storage Pool
proposed in your email.
However I think that two queries (onevm show + oneimage show) is a bit
cumbersome, my proposal here is to include a special Image attribute
(TM_OPTIONS or DISK_ATTRIBUTES) that will be copied form the IMAGE to
the DISK attribute in the VM template (when the VM is created), so a
simple onevm show will give you those values.
What do you think?
With this method the metadata "how is the disk accessed" is attached to
the image. I see a two problems with this :
- I will need to create two images if I want to deploy the same image
on both local disks and iscsi (see the URL point earlier).
- It cannot be applied to swap, contextualization images, or disks not
built from images.
I do however like the idea of setting a default value for TM_OPTIONS on
the image. That way, I could specify that a CD Image is always accessed
through NFS unless specified otherwise. I just checked : unknown options
are kept and can be accessed with "oneimage show", provided we know the
id or the name of the image.
--
Vivien
_______________________________________________
Users mailing list
[email protected]
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
