Request #666

Copy links as links rather than files when registering an image

Added by Vivien Bernet-Rollande over 9 years ago. Updated over 9 years ago.

Status:ClosedStart date:05/31/2011
Priority:NormalDue date:
Assignee:Ruben S. Montero% Done:

0%

Category:Core & System
Target version:-
Pull request:

Description

Quick background : I'm writing a TM driver that uses iscsi to store VM images. This TM driver relies on links to the /dev/disk/by-path/ip* tree.
I have the following link structure :
/srv/cloud/1/images/disk.0 -> /dev/disk/by-path/ip-1.2.3.4:3260-iscsi-iqn.1992-08.com.filer:cloudfiler01-lun-0
/dev/disk/by-path/ip-1.2.3.4:3260-iscsi-iqn.1992-08.com.filer:cloudfiler01-lun-0 -> /dev/sdb

Preliminary tests seem to indicate it works. My TM connects to the filer, adds/clones/deletes LUNs efficiently, and manages permissions on said LUNs.

Now, to the issue at hand. What I would like, is the ability to provision images that are "LUNs on a filer".

The problem is that when "oneimage register" is run, the content of the LUN is copied to the disk.

Browsing through the code, it appears that the code responsible for this is OpenNebula::ImageRepository#copy(). This method calls Fileutils.copy(), which, according to documentation will read the content pointed to by a symlink, and write it to a new file.

The Fileutils.copy_entry() method, on the other hand, will actually keep the link.

I'm using the attached patch. I'm aware all this code no longer exists in soon-to-be 2.4, and it's unlikely to be merged in anything, so I'm leaving this here in case someone else needs it.

one_copy_entry.patch Magnifier (537 Bytes) Vivien Bernet-Rollande, 05/31/2011 12:14 PM

History

#1 Updated by Ruben S. Montero over 9 years ago

  • Status changed from New to Closed

Hi Vivien,

We have been working on this for the next release. The image repository has been decoupled and architected using a plugin approach similar to the other OpenNebula components. In this way there are external programs called to cp, mv, rm, mkfs images in the repo that implements specific operations depending on the storage backend for the repo.

This is already in master. I am closing this issue, as the changes you propose can be easily included in the new structure.

Thanks for your feedback!

Also available in: Atom PDF