[one-users] some features we'd like to have in OpenNebula

[Ruben S. Montero]

Hi Valerio,

Thank you very much for sharing, this feedback is very useful for use.
I think that most of the machinery needed to cover your use-cases is
already there.

1.- Timed. I think that can very easily implemented by combining two things
 * Annotate the VM templates with a TTL
 * Have a (very simple script) that iterate over the onevm list -x out
put and checks time() with the startime + TTL. All that information is
in the VMs. and a ruby/python script would take just a few lines....

You can easily program the execution of this script in cron

2.- Exclusive allocation. You can use REQUIREMENTS = "RVMS=0", this
will only pick hosts with no RVMS. Note that when scheduling a set of
machines this is evaluated just once per scheduling instance so be
sure to put MAX_HOST=1 in sched.conf (default value)

As you said this two can be combined.....

Does it make sense?

Cheers

Ruben

On Wed, Dec 12, 2012 at 4:00 PM, Valerio Schiavoni
<valerio.schiavoni at gmail.com> wrote:
> Dear all,
> at our university we use OpenNebula 3.6 to manage our 62-cluster machine. So
> far so good, and it's been a real pleasure to use.
>
> After some 6 months of usage, we have some use-cases that we currently don't
> find implemented in the platform.
> I post them here in case others have worked them out already and to gather
> some  feedback.
> I've quickly skimmed over the 3.8 documentation and these use-cases don't
> seem to be targeted yet:
> if that's the case, a pointer to such documentation will suffice.
>
> 1) Timed deployments.
> It would be useful to restrict VM deployments for a fixed duration in time.
> Timings should be given either in a relative format (ie, starts now, finish
> in 2 hours), or absolute (ie, starts the 24 of December at midnight, ends by
> the 1st of January/1 week). The actions to take at expiration time should be
> configurable at deployment (suspend, stop, delete VM, etc). Email
> notifications close to and at expiration time would be a nice addition.
>
> 2) Shared vs Reserved deployments.
> Usually, VMs get deployed over physical machines  hosting already other VMs.
> We'd like an option to restrict certain types of VMs to be allocated only on
> hosts that currently host zero VMs.
> Such hosts, once assigned to run a given VM, are temporarily out of the pool
> of available hosts.
> This allows  us to run VMs for performance-driven tests - typically of short
> duration.
> Reserved deployments should have a  duration that is typically shorter than
> shared deployments.
> What would be the best way to implement this?  We considered splitting the
> pool of hosts in two blocks (shared and reserved), but then how can we
> configure the scheduler accordingly to respect such shared/reserved scenario
> ?
>
> There are some combinations of these 2 use-cases that could be interesting
> for use in combination with the quota system: for example to restrict the
> total number of shared and reserved concurrent deployments allowed to a
> given user.
>
>
> Please let me know if something close to these scenarios already exist.
> Best regards,
> Valerio
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>



-- 
Ruben S. Montero, PhD
Project co-Lead and Chief Architect
OpenNebula - The Open Source Solution for Data Center Virtualization
www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula