Hey Alena, Why would we want to explicitly add a vlan for "isolated" networks without source nat service? The guest IP allocator works for that scenario and the network is not supposed to be shared. I'm actively working with this part of the code as currently the some of the create code explicitly checks for vlan tags before deciding if the IP networks overlap. However with the SDN code there is no such thing as a vlan, but the network is still "private". I'm trying to see which parts of the code should be changed to allow it to work with the SDN code.
Next to that there is an inconsistency in the permissions, it is possible for a domain-admin to create an isolated network without SourceNat. The network is actually created, but the ip addresses are not added to the vlan and user_ip_address tables. This would cause an exception when creating a VM in this network as there are no IP addresses allocated. I think domain admins should be able to create these types of networks. Am I making any sense at all? Hugo -----Original Message----- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Tuesday, August 07, 2012 10:51 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Networking question Hugo, Sorry, completely missed this scenario. When I referred to ip allocation in Isolated network in my email, I meant Isolated network with Source Nat service. 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. -Alena. On 8/7/12 1:38 PM, "Hugo Trippaers" <htrippa...@schubergphilis.com> 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. > >Cheers, > >Hugo > >Sent from my iPhone > >On 7 aug. 2012, at 20:14, "Alena Prokharchyk" ><alena.prokharc...@citrix.com> wrote: > >> On 8/7/12 6:14 AM, "Hugo Trippaers" <htrippa...@schubergphilis.com> >>wrote: >> >>> 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 >>>networks. >>> 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 network. >>> 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 a 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 >>>internal network for domain. When creating the VM the >>>GuestNetworkGuru (line >>>402) >>> 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 add 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 >>needed. >> >> -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 >>> >>> >>> >> >> >
