<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 04/18/11 10:55, Jaime Melis wrote:
<blockquote
cite="mid:BANLkTi=OJO4hRk6ak8-D9BO8eZHOi+3Pvw@mail.gmail.com"
type="cite"> <span class="Apple-style-span"
style="border-collapse: collapse; color: rgb(68, 68, 68);
font-family: arial,sans-serif; font-size: 13px;">
<div>Hi Viven,</div>
<div><br>
</div>
<div>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.</div>
</span></blockquote>
I've seen this example, but I didn't find it quite flexible enough.<br>
<blockquote
cite="mid:BANLkTi=OJO4hRk6ak8-D9BO8eZHOi+3Pvw@mail.gmail.com"
type="cite"><span class="Apple-style-span" style="border-collapse:
collapse; color: rgb(68, 68, 68); font-family: arial,sans-serif;
font-size: 13px;">
<div>* 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'.</div>
</span></blockquote>
<blockquote
cite="mid:BANLkTi=OJO4hRk6ak8-D9BO8eZHOi+3Pvw@mail.gmail.com"
type="cite"><span class="Apple-style-span" style="border-collapse:
collapse; color: rgb(68, 68, 68); font-family: arial,sans-serif;
font-size: 13px;">
<div><br>
</div>
<div>* 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</div>
<div><br>
</div>
</span></blockquote>
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 :<br>
CLONE <a class="moz-txt-link-freetext" href="http:///srv/cloud/images/debian.img">http:///srv/cloud/images/debian.img</a>
192.168.0.74:/var/lib/one//26/images/disk.0<br>
<br>
I have no simple way to know if /var/lib/one//26/images/disk.0
should point to iscsi or nfs storage.<br>
Of course I could specify something like
<a class="moz-txt-link-freetext" href="http:///srv/cloud/images/debian.img@iscsi/filer1/target1/">http:///srv/cloud/images/debian.img@iscsi/filer1/target1/</a>, but I
would need to create images for
<a class="moz-txt-link-freetext" href="http:///srv/cloud/images/debian.img@local/">http:///srv/cloud/images/debian.img@local/</a>,
<a class="moz-txt-link-freetext" href="http:///srv/cloud/images/debian.img@iscsi/filer2/target34/">http:///srv/cloud/images/debian.img@iscsi/filer2/target34/</a>, or
<a class="moz-txt-link-freetext" href="http:///srv/cloud/images/debian.img@nfs/filer1/path/to/share/">http:///srv/cloud/images/debian.img@nfs/filer1/path/to/share/</a>.<br>
<br>
I find such a hack unnecessarily complex, and very
counter-intuitive.<br>
<blockquote
cite="mid:BANLkTi=OJO4hRk6ak8-D9BO8eZHOi+3Pvw@mail.gmail.com"
type="cite"><span class="Apple-style-span" style="border-collapse:
collapse; color: rgb(68, 68, 68); font-family: arial,sans-serif;
font-size: 13px;">
<div>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. </div>
<div><br>
</div>
</span></blockquote>
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):<br>
<br>
DISK=[<br>
CLONE=NO,<br>
DISK_ID=0,<br>
READONLY=no,<br>
SOURCE=/srv/cloud/images/debian.img,<br>
TARGET=sda1,<br>
TM_OPTIONS=--foo=bar --bar=baz ]<br>
<br>
So it would be possible to write a "very smart" TM that would :<br>
- the VM ID from $SRC_PATH<br>
- get the disk ID from $DST_PATH<br>
- parse the output of onevm show, and extract the value of
TM_OPTIONS.<br>
- if no options are found, parse output of oneimage show.<br>
<br>
However, this is complex, and therefore error prone and hard to
maintain.<br>
<br>
<blockquote
cite="mid:BANLkTi=OJO4hRk6ak8-D9BO8eZHOi+3Pvw@mail.gmail.com"
type="cite"><span class="Apple-style-span" style="border-collapse:
collapse; color: rgb(68, 68, 68); font-family: arial,sans-serif;
font-size: 13px;">
<div>I think that this approach is pretty close to the Storage
Pool proposed in your email. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>What do you think?</div>
</span></blockquote>
With this method the metadata "how is the disk accessed" is attached
to the image. I see a two problems with this :<br>
- 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).<br>
- It cannot be applied to swap, contextualization images, or disks
not built from images.<br>
<br>
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.<br>
<br>
--<br>
Vivien<br>
<br>
</body>
</html>