[one-dev] proof of concept implementation of EXTERNAL leases

Steven Armstrong steven-opennebula at armstrong.cc
Thu Dec 19 07:01:03 PST 2013


Ruben S. Montero wrote on 12/19/2013 03:34 PM:
> Hi Steven
>

Hi Rubén

> Sorry for the dealy. This is very interesting indeed. Usually we implement
> this feature the other way around, a hook registers the IP assigned by
> OpenNebula to the DHCP server. Obviously, this cannot be assumed in all
> deployments.

My problem with this is that the networks are shared with physical 
machines. So I can't let OpenNebula manage them. I could preallocate a 
number of IPs in each subnet for virtual machines but that feels like a 
hack.

So I thought I could either add a lease and somehow reserve it for a 
specific vm, preferably by mac address. But this does not seem to be 
possible.

So I came up with the idea of EXTERNAL leases.

> Thinking about this, I'd like to leverage the hook system. The goal is to
> manage the excution to an external driver and decouple it for the core it
> self. However, there are a couple of issues to address, as we need to
> synchronize IP and VM structures.

Happy with that if it gives me what I need ;-)

> Could we somehow get around this by  implementin a API call to update the
> IP address?

Possible, but in the mean time I found this [1] which I think could also 
solve my problems. Together with some new hooks it could handle all use 
cases I can think of. [2] is maybe related.

For me it would be best if OpenNebula would not care about IP addresses 
at all. From my limited understanding (noob alert here) the vms IP's are 
not used by OpenNebula directly anyway. Is this correct?

What I do when we get a new physical machine is:
- get mac from hardware or supplier
- define ip to mac binding via dhcp
- define hostname to ip binding via dns

I'd like to treat vms exactly the same. Only difference that OpenNebula 
gives me the mac address instead of my hardware supplier.

Cheers,
Steven

[1] http://dev.opennebula.org/issues/2545
[2] http://dev.opennebula.org/issues/1958



More information about the Dev mailing list