[one-users] Sparse Images with 2.0

[Carlos Martín Sánchez]

Hi Frank,

You could modify the core to make it keep the SIZE sub-attribute in the DISK
attributes, but that seems rather complex for what you need.
It looks to me that the best approach would be #2, considering you have
already your custom transfer scripts. You could just add a new attribute,
something like

DISK = [ IMAGE = "imageA" ]
DISK_SIZE = [ DISK_ID = 0, SIZE = 1024 ]

DISK = [ IMAGE = "imageB" ]
DISK_SIZE = [ DISK_ID = 1, SIZE = 2048 ]


Or a more readable option

DISK = [ IMAGE = "imageA" ]
DISK_SIZE = [ IMAGE = "imageA", SIZE = 1024 ]

DISK = [ IMAGE = "imageB" ]
DISK_SIZE = [ IMAGE = "imageB", SIZE = 2048 ]


Regards,
Carlos.


Carlos Martín, Cloud Technology Engineer/Researcher
DSA Research Group: web http://dsa-research.org and blog
http://blog.dsa-research.org
OpenNebula Open Source Toolkit for Cloud Computing:
http://www.OpenNebula.org


On 13 September 2010 20:19, Frank Stutz <frank at franksplace.net> wrote:

> In my configuration we have small OS images (~ 1GB) and we allow the users
> to use this image and expand the size as needed (via sparse image dd script)
> as we don't have shared storage.   I have been leveraging the DISK -> SIZE
> operation in the 1.4 template code base along with custom transfer manager
> script to accomplish this today.  This has been working great and I've been
> happy with it.  My question is with the changes in the 2.0 branch and with
> the new images repo, what would be the best way to accomplish this task?
> I'm all on board with the new 2.0 image structure, but I'm trying to figure
> out how to proceed.
>
> Thoughts I have so far:
> 1.  Modify the code to allow the SIZE option to be retained even though
> image is specified; right now any extra template parmeters are removed
> before saving to DB
> 2.  Create a special new parameter for sparse imaging growth, and modify tm
> custom scripts to accommodate
> 3.  Throw out the whole tm custom scripts methodology and use hooks, but
> still need method to store SIZE of final image in DB.
> 4.  Use context, but modify it to work before image is booted.
>
> Right now I'm thinking modifying the code to allow the SIZE option to
> propagate to the DB if a IMAGE is desired would be the best way to go, but
> wanted some insight if this is best approach?
>
>
> --Frank
>
> _______________________________________________
> 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/20100924/f0f51fda/attachment.htm>