[one-users] greetings

Valentin Bud valentin.bud at gmail.com
Fri Jun 20 00:55:37 PDT 2014


Hello Galimba,

I would like to kindly welcome you to the magic world of Cloud Computing
:). I think
your decision to use OpenNebula for your needs was a wise one. A road filled
with fun, amusement and sometimes frustrations lay ahead. Enjoy.

When I've first read your E-Mail I thought at exactly the same solution as
the one
pointed out by you, connect to the firewall and modify the iptables rules.
I would
choose to modify them via a hook [1] because I don't like to mangle with
deploy.

You might ask why is that? In case of update in the future you don't have
to worry
that your deploy script gets overwritten. Another safe option would be to
copy
the whole virtualization manager and name it kvm-local and modify the deploy
script there and update the hosts to use that driver.

Another solution that came to mind is to define a pseudo public network in
ONE
using a desired private range. Then map the last octet from you public
range with
the one in this private range. Easier to remember, though your users might
not
agree. I think it's easier if I write an example.

Public: X.Y.Z.*100* <> Private: 172.16.0.*100*

On the firewall you would have to DNAT each of those one 100 IP addresses
to each
of those private ones. You would have to do this once. For speed you can
generate
the rules with a basic for.

Next step would be to hold [2] all the IPs from the private network (pseudo
public)
that you don't have available in the Public range.

Not elegant, not user friendly but a (working) solution non the less.

The most elegant solution I am aware of would be to create a VLAN
subinterface
for that /25 range on the firewall and configure a true public network
inside ONE.
It could even be done with bridging only without the hassle of setting up
VLANs.
But you need to be able to partition your network in this manner. It might
not
work for you.

You're challenge is a really interesting one and I would like to hear other
people
opinions and possible solutions. It gave me food for thought and I am
grateful for
that.

[1]:
http://docs.opennebula.org/4.4/integration/infrastructure_integration/hooks.html
[2]:
http://docs.opennebula.org/4.4/user/virtual_resource_management/vgg.html

Best,
Valentin



On Fri, Jun 20, 2014 at 12:27 AM, Galimba <galimba at gmail.com> wrote:

> Hello everyone.
> My name is Sebastian. I'm new to this list and tho I've been a sysadmin
> for several years now, I've only recently dived into Cloud Computing.
> I have successfully installed OpenNebula 4.4 on a local computer behind a
> firewall at my university. I set up two nodes and another dedicated
> computer as a NFS datastore.
> The plan is to provide my research group with the IAAS that OpenNebula
> brings to the table.
> At the moment, I'm dealing with an issue I haven't been able to solve, and
> perhaps some of you could throw me a hint.
> My university assigned me over 100 public ip addresses to provide each VM.
> If I were to plug the cable directly to the OpenNebula box, then I know I
> could create my templates with public ip addresses and then everything
> should be fine. The problem is that I have a firewall in the middle,
> managing all the public ips, and my OpenNebula box is on a LAN behind that
> firewall.
> Is there an easy (and safe) way to assign public ips and pass tru the
> iptables on the firewall? I mean... the only solution I came up with was to
> modify the deploy script on the OpenNebula box to connect to the firewall
> and modify the iptables rules regarding the particular VM I'm trying to
> deploy. That's not a very happy solution.
> Thanks in advance.
> galimba
>
> --
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>


-- 
Valentin Bud
http://databus.pro | valentin at databus.pro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20140620/a548cf41/attachment.htm>


More information about the Users mailing list