incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: Networking question
Date Tue, 07 Aug 2012 20:50:54 GMT

Sorry, completely missed this scenario. When I referred to ip allocation
in Isolated network in my email, I meant Isolated network with Source Nat

IP allocation for Isolated network with no source Nat falls under the same
rules Shared network follows. Both these networks used to be called
"Direct" in previous releases; and for both networks the Vlan has to be
added explicitly. 

"Virtual" network is always an equivalent to Isolated Network with Source
Nat service enabled.


On 8/7/12 1:38 PM, "Hugo Trippaers" <> wrote:

>Hey Alena,
>Thanks for the explanation, but in my case the network that I'm creating
>is an isolated network without a SourceNat offering.
>So it should not need have an ip allocated from the public ip table as it
>is isolated. It is also not a VLAN but a 'direct' network as it is
>provisioned by the Nicira stack.
>I have a work around now that checks if there is a vlan defined on this
>network using the vlanDao and if there is not the guest allocator is used.
>Sent from my iPhone
>On 7 aug. 2012, at 20:14, "Alena Prokharchyk"
><> wrote:
>> On 8/7/12 6:14 AM, "Hugo Trippaers" <>
>>> Heya,
>>> I'm trying to get my head around something and would welcome some
>>> feedback.
>>> The use case I'm currently working with is related to internal
>>> I have serveral use cases that call for internal networks that have no
>>> connection to the outside world. Say I have a couple of webservers with
>>> one nic in a sourcenat-ted network and one nic in a dedicated DB
>>> And a couple of DB servers that are only located in the DB network. (A
>>> similar scenario is where the VMs exist in an already existing VLAN or
>>> bridged network using a Nicira Nvp Gateway)
>>> As admin I have created a networkoffering with just DHCP, DNS and
>>> UserData enabled and no other services. As a domain-admin I can create
>>> network based on that offering via the API and give it an ip range
>>>that I
>>> want. When creating a VM in that network I get a message saying that I
>>> can allocate an address.
>>> If I create this network as a domain-admin the last step in
>>> createNetwork(CreateNetworkCmd) in NetworkManagerImpl, the call to
>>> createVlanAndPublicIpRange(), is skipped. This is OK as it is an
>>> network for domain. When creating the VM the GuestNetworkGuru (line
>>> assumes that it should get an IP using the allocateDirectIp call. This
>>> goes wrong as there are no IP's in the "public" pool for this lan.
>>> I would like to change this piece in GuestNetworkGuru to check if the
>>> public range is in the public ip table and if it's not use the
>>> acquireGuestIpAddress call to reserve an IP.
>> Hugo, there is a difference in how we maintain ip addresses for Isolated
>> networks and Shared networks.
>> 1) For Isolated networks, any IP address from the CIDR defined on the
>> network level, can be used for vm deployment. So whenever
>> acquireGuestIpAddress is called, we:
>> * get the network cidr
>> * figure out all ip addresses used from this cidr by existing vms - this
>> info it taken from Nics table. Put these ip addresses to avoid set.
>> * randomly pick up any free ip address (considering the avoid set) from
>> the cidr space.
>> 2) For Shared networks, the IP ranges are kept in user_ip_address table.
>> There can be non-contiguous ip ranges - you can add every range using
>> createVlanIpRange admin API. And the ip allocation algorithm is quite
>> different here, as we can't just rely on the cidr and assume that all ip
>> addresses from the cidr can be used as we do in Isolated network case.
>> Every time we have to allocate ip address from the Shared range for the
>> vm, we look at the user_ip_address table and pick up any FREE ip address
>> from the network. If there are no free ip addresses left, admin has to
>> more using createVlanIpRange API.
>> So we can't use acquireGuestIpAddress call for Shared networks.
>> Let me know if the explanation is clear enough, or more details are
>> -Alena.
>>> But as I'm not completely sure about the reasoning behind this I would
>>> like some feedback on my reasoning before I break stuff in other places
>>> :-)
>>> Cheers,
>>> Hugo

View raw message