[one-users] econe toolset

Tue Mar 2 05:22:14 PST 2010

Oh, I forgot to mention that... At the end is a copy of my m1.small.erb:

Im am using tm_nfs for my deployment.

The modifications I performed have to do with the chmod commands issued on
the tm* commands. They now look like this:

[tsbatista at fpa1 nfs]$ grep chmod *
tm_clone.sh:exec_and_log "chmod a+rw $DST_DIR"
tm_clone.sh:exec_and_log "chmod a+rw $DST_PATH"
tm_ln.sh:exec_and_log "chmod a+w $DST_DIR"
tm_mkimage.sh:exec_and_log "chmod a+rw $DST_PATH"
tm_mkswap.sh:exec_and_log "chmod a+w $DST_DIR"
tm_mkswap.sh:exec_and_log "chmod a+w $DST_PATH"

This now allows the Xen process to read and write on to the images. I do not
like to have a+rw for the permissions on any file, but given that I am the
only user on the dom0, I can live with this!

Note that no modification was not made to mkswap because it alredy takes
advantage of the default permissions issued to a new file (a+r), so it only
has to add the read permission. However tm_clone was assuming that the
original permissions included a+r, but that is not the case if the image is
uploaded via econe as it somehow restricts the permissions on the uploaded
file.

My sugestion is to change all those chmod ?+? to chmod 666 as that does not
make any assumptions on the files initial permissions, it just sets all the
permissions and no error will come of it (777 for directories)

By the way... How much work do you estimate to make econe-server work with
clients developed for ec2? Are there many missing calls?

Tiago

-----------------------
NAME   = eco-vm

CPU    = 0.5
MEMORY = 128

OS = [ bootloader = /usr/bin/pygrub ]

DISK = [ source   = <%= erb_vm_info[:img_path] %>,
         clone    = yes,
         target   = xvda1,
         readonly = no]

DISK = [
  type     = swap,
  size     = 512,
  target   = "xvdb",
  readonly = "no" ]

IMAGE_ID = <%= erb_vm_info[:img_id] %>
INSTANCE_TYPE = <%= erb_vm_info[:instance_type ]%>

NIC = [NETWORK="Xen Network"]

CONTEXT = [
  hostname   = "$NAME-$VMID",
  username   = "tsbatista",
  target     = "xvdz",
  files      = "/home/tsbatista/.ssh/id_rsa.pub
/home/tsbatista/one-conf-data/context/init.sh"
]

On Tue, Mar 2, 2010 at 12:44 PM, Tino Vazquez <tinova at fdi.ucm.es> wrote:

> Hi Tiago,
>
> What TM are you using (ssh or nfs?). Could it be a problem with your
> creation mode mask?
>
> It is weird that disk.0 and disk.1 have different permissions. BTW,
> did you modify the m1.small.erb template (i don't see otherwise how
> there are two files)?
>
> Regards,
>
> -Tino
>
> --
> Constantino Vázquez, Grid & Virtualization Technology
> Engineer/Researcher: http://www.dsa-research.org/tinova
> DSA Research Group: http://dsa-research.org
> Globus GridWay Metascheduler: http://www.GridWay.org
> OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
>
>
>
> On Thu, Feb 25, 2010 at 8:52 PM, Tiago Batista <tiagosbatista at gmail.com>
> wrote:
> > Hello all
> >
> > I have been testing the econe tools today, and there are a few details...
> >
> > First of, thank you Claude for your timeout patch, if I saw it right, it
> > also solved the same problem with econe-upload!
> >
> > Now the problem... After uploading a few images, I end up with the
> > folloowing on my images dir:
> >
> > -rw------- 1 tsbatista users  2148532224 Feb 25 18:16 1
> > -rw------- 1 tsbatista users  1074790400 Feb 25 18:44 2
> > -rw------- 1 tsbatista users  1074790400 Feb 25 19:06 3
> >
> > now, I call econe-run-instances, and I suddenly get this on the vm.log
> >
> > Command execution fail: 'cat >
> > /home/tsbatista/datastore/77/images/deployment.0 && sudo /usr/sbin/xm
> create
> > /home/tsbatista/datastore/77/images/deployment.0 && sudo /usr/sbin/xm
> > sched-cred -d one-77 -w 128'
> > Thu Feb 25 19:20:42 2010 [VMM][I]: STDERR follows.
> > Thu Feb 25 19:20:42 2010 [VMM][I]: No handlers could be found for logger
> > "xend"
> > Thu Feb 25 19:20:42 2010 [VMM][I]: Error: Disk isn't accessible
> > Thu Feb 25 19:20:42 2010 [VMM][I]: ExitCode: 1
> >
> >
> > After removing the last command from tm_delete.sh, I pinned it down to
> the
> > following:
> >
> > GOOD:
> > [tsbatista at parlamento images]$ ls -l ../../78/images/
> > total 499748
> > -rw-r--r-- 1 tsbatista users         344 Feb 25 19:34 deployment.0
> > -rw-rw-rw- 1 tsbatista users 10486808576 Feb 25 19:39 disk.0
> > -rw-rw-rw- 1 tsbatista users   536870913 Feb 25 19:34 disk.1
> > -rw-r--r-- 1 tsbatista users      376832 Feb 25 19:34 disk.2
> >
> > BAD:
> > [tsbatista at parlamento images]$ ls -l
> > total 1051024
> > -rw-r--r-- 1 tsbatista users        344 Feb 25 19:20 deployment.0
> > -rw--w--w- 1 tsbatista users 1074790400 Feb 25 19:28 disk.0
> > -rw-rw-rw- 1 tsbatista users  536870913 Feb 25 19:20 disk.1
> > -rw-r--r-- 1 tsbatista users     376832 Feb 25 19:20 disk.2
> >
> > as you can see, tm_clone is not setting the right permissions for the
> cloned
> > disk... I fixed this on my local install, but still would like to know if
> > this is by design or a bug...
> >
> > Thank you all
> >
> > Tiago
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opennebula.org
> > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20100302/b7a7fe48/attachment.htm>