Hi,
I found working (ugly) workaround - create two virtual networks with
same IP addresses. Put router IP on hold on user accessible vnet and use
another vnet for router. That works for ebtables, but for openvswitch
that will require VLAN_ID sharing.
Also default ACL (rule 0) allows users to create virtual networks, what
will allow access other users virtual networks by guessing IP addresses,
VLAN_ID and bridge names.
Regards, Rolandas
On 2013-01-16 21:11, Rolandas Naujikas wrote:
On 2013-01-16 19:35, Ruben S. Montero wrote:
Hi
Something we've done in the past for some setups is to create vnets for
specific users. The network has an initial set of pre-assigned IP's that
can be used only by the vnet owner. An external provisioning program
adds/deletes leases to the user network, when needed (e.g. run out of
IP's...).
Maybe an approach similar to that one is useful for your use-case.
Virtual router (from opennebula marketplace) expects private network
interface on ranged virtual network and current implementation doesn't
work with this approach.
Regards, Rolandas
P.S. Currently I have to create our own clean installation of virtual
router to workaround opennebula limitations or to introduce changes in
/usr/share/opennebula/init.rb in virtual router of opennebula.
P.S. Also there I want to have multiple FORWARDING rules to map access
for e.g. to ssh port on every IP in virtual network (like 22000+ip.4 on
router redirected to ip:22, where ip.4 is the last component of ip).
Cheers
Ruben
On Wed, Jan 16, 2013 at 4:22 PM, Carlos Martín Sánchez
<cmar...@opennebula.org <mailto:cmar...@opennebula.org>> wrote:
Hi,
VNet hold/release is not meant for your use case, it was implemented
to hold IPs that may be temporarily used by a physical host, or some
machines not managed by OpenNebula.
Maybe you could put your VM in the hold state [1], that will take
the vnet lease, and you can later release the VM to be deployed.
Regards
[1]
http://opennebula.org/documentation:rel3.8:vm_guide_2#life-cycle_operations
--
Carlos Martín, MSc
Project Engineer
OpenNebula - The Open-source Solution for Data Center Virtualization
www.OpenNebula.org <http://www.OpenNebula.org> |
cmar...@opennebula.org <mailto:cmar...@opennebula.org> | @OpenNebula
<http://twitter.com/opennebula><mailto:cmar...@opennebula.org>
On Wed, Jan 16, 2013 at 2:47 PM, Rolandas Naujikas
<rolandas.nauji...@mif.vu.lt <mailto:rolandas.nauji...@mif.vu.lt>>
wrote:
Hi,
When trying to configure virtual router VM I got into a problem.
I want to configure its private IP fixed to some low IP (e.g.
10.1.1.1).
I'm creating virtual (isolated) network X, where I defines
IP_START=10.1.1.3, IP_END=10.1.1.254, but opennebula doesn't
allow instantiate a VM with NIC=[IP=10.1.1.1,NETWORK=X], because
10.1.1.1 is not in range IP_START to IP_END.
If I put IP_START=10.1.1.1 to X, then some other user VM could
take this IP. If I put 10.1.1.1 on hold (onevnet hold), then I
cannot start VM with this IP until I release it (onevnet
release), but there is always some time window when someone from
users could take it. It looks like onevnet hold/release is
almost useless.
Regards, Rolandas
_________________________________________________
Users mailing list
Users@lists.opennebula.org <mailto:Users@lists.opennebula.org>
http://lists.opennebula.org/__listinfo.cgi/users-opennebula.__org
<http://lists.opennebula.org/listinfo.cgi/users-opennebula.org>
_______________________________________________
Users mailing list
Users@lists.opennebula.org <mailto:Users@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 <http://www.OpenNebula.org> |
rsmont...@opennebula.org <mailto:rsmont...@opennebula.org> | @OpenNebula
_______________________________________________
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
