[one-users] Using Opennebula with a uncommon Xen-configuration

[Vivien Bernet-Rollande]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20110418/506495f5/attachment-0003.htm>