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 >> >> >> > >
