<!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>