[one-ecosystem] Integrating with a network provisioning service.

[Jaime Melis]

Hello Dimitris,

This sounds like a really great component and I believe it will fit
properly with OpenNebula.

Regarding your question, I think you might consider the approach we've
followed in OpenNebula 3.2. We dropped the hooks system we had for networks
and instead we integrated the network drivers with the VM's lifecycle. What
this really means is that besides the scripts specific to the hypervisor
(deploy, migrate, shutdown, etc) there are 3 extra scripts that are
executed during a VM's lifecycle: pre, post and clean.

- pre: it's executed right before the deploy script. If it returns an
error, the VM won't be deployed
- post: it's executed right after the deploy script. If it returns an error
the VM will be cancelled and rollbacked.
- clean: it's executed after the shutdown script.

At all times during these script you know in which host the VM is going to
be deployed (pre) os in which host it has been deployed (post and clean).

Take a look at these scripts:
https://github.com/OpenNebula/one/tree/one-3.2/src/vnm_mad/remotes/802.1Q

I think this a more robust approach than modifying the scheduler.

Just out of curiosity take a look at this, where the order of the scripts
(pre-deploy-post) is defined for the deploy action:
https://github.com/OpenNebula/one/blob/one-3.2/src/vmm_mad/exec/one_vmm_exec.rb#L278

Let me know if this works for you,

Cheers,
Jaime

On Thu, Mar 15, 2012 at 12:50 PM, Dimitris Theodorou <dtheodor at nikhef.nl>wrote:

> Hi,
>
> I am working on a cloud network resource provisioning service, which will
> accomodate networking among virtual machines by configuring the network
> hardware(switches) that lies between the hosts. The goal of the service is
> 1) to undo the "vlan clean" requirement that you have in OpenNebula and
> other cloud stacks, 2) to be able to provide bandwidth requests and 3) to
> take decisions on how the network will be allocated based on the current
> switching and network infrastructure of the cluster that hosts the cloud
> service. The service should also easily support any switch model.
>
> The simplest functionality of the system (let's call it NRS) is that it
> receives a request containing a network id, as well as the VM hosts that
> should be connected to it. It then chooses a suitable vlan (if not given),
> and configures host bridges and switches involved so that the network is
> realized.
>
> I am using OpenNebula to build a prototype of the system. To interface
> with it, the idea is that I need a single point during OpenNebula execution
> after VMs are assigned to hosts but before the VMs are launched. The
> Vm-host info is to be sent to NRS, which will respond whether OpenNebula
> can proceed with launching VMs.
>
> Currently, the opennebula scheduler assigns a limited amount of VMs per
> host in each cycle, and the decision process is restarted for every cycle.
> This creates a problem (for NRS) because there is no single point during
> execution where you have all VM-to-host assignments before VMs are
> launched. In order to work around this, I modified the scheduler to assign
> all hosts to VMs at once, and defer the actual deployment to following
> scheduler cycles.
>
> Now my question is:
>
> Is the above solution the proper way to go, or is there is a better way to
> address this that I am missing? Also if you have any comments/criticism on
> the project and how it fits with OpenNebula I would be happy to hear them.
>
> Dimitris
>
>
> ______________________________**_________________
> Ecosystem mailing list
> Ecosystem at lists.opennebula.org
> http://lists.opennebula.org/**listinfo.cgi/ecosystem-**opennebula.org<http://lists.opennebula.org/listinfo.cgi/ecosystem-opennebula.org>
>



-- 
Jaime Melis
Project Engineer
OpenNebula - The Open Source Toolkit for Cloud Computing
www.OpenNebula.org | jmelis at opennebula.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/ecosystem-opennebula.org/attachments/20120320/0688d648/attachment-0001.htm>