Hello Dimitris,<div><br></div><div>This sounds like a really great component and I believe it will fit properly with OpenNebula.</div><div><br></div><div>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.</div>

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

<div>- clean: it's executed after the shutdown script.</div><div><br></div><div>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).</div>

<div><br></div><div>Take a look at these scripts:</div><div><a href="https://github.com/OpenNebula/one/tree/one-3.2/src/vnm_mad/remotes/802.1Q">https://github.com/OpenNebula/one/tree/one-3.2/src/vnm_mad/remotes/802.1Q</a><br>

</div><div><br></div><div>I think this a more robust approach than modifying the scheduler.</div><div><br></div><div>Just out of curiosity take a look at this, where the order of the scripts (pre-deploy-post) is defined for the deploy action:</div>

<div><a href="https://github.com/OpenNebula/one/blob/one-3.2/src/vmm_mad/exec/one_vmm_exec.rb#L278">https://github.com/OpenNebula/one/blob/one-3.2/src/vmm_mad/exec/one_vmm_exec.rb#L278</a><br></div><div><br></div><div>Let me know if this works for you,</div>

<div><br></div><div>Cheers,<br>Jaime</div><div><br><div class="gmail_quote">On Thu, Mar 15, 2012 at 12:50 PM, Dimitris Theodorou <span dir="ltr"><<a href="mailto:dtheodor@nikhef.nl">dtheodor@nikhef.nl</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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.<br>


<br>
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.<br>


<br>
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.<br>


<br>
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.<br>


<br>
Now my question is:<br>
<br>
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.<br>


<br>
Dimitris<br>
<br>
<br>
______________________________<u></u>_________________<br>
Ecosystem mailing list<br>
<a href="mailto:Ecosystem@lists.opennebula.org" target="_blank">Ecosystem@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/ecosystem-opennebula.org" target="_blank">http://lists.opennebula.org/<u></u>listinfo.cgi/ecosystem-<u></u>opennebula.org</a><br>
</blockquote></div><br></div><br clear="all"><div><br></div>-- <br>Jaime Melis<br>Project Engineer<br>OpenNebula - The Open Source Toolkit for Cloud Computing<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a><br>