LAB 3.1 Task 5: Log into the new instances ( Nova Networking)
neghtedari
Posts: 12
Note : this is not a problem report for lab 3.1 but rather a general question.
Instead of launching the lab environment for the Lab 3.1, I decided to continue my work from the Launched lab environment from Lab 2.1 and noticed that once it gets to this section, when I try to launch a new instance, it will not receive any IP address because I removed the following lines from local.conf before running the stack.sh script.
#FIXED_RANGE=10.10.128.0/20 #Range for private IPs
#FLOATING_RANGE=192.168.100.128/25 #Range for public IPs
Now i'm trying to figure out how to allocate that IP address manually and can't find any option to that and wondering if I'm simply missing an option somewhere or it is not possible...
Also, I'm having a hard time to understand what is happening in here; for example, in VMware or KVM environment, as far as I know, we never need to assign fixed or floating range anywhere, you simply allocate an IP to your host and afterward you can launch as many VMs with whatever IP you want. of course, if you want those IPs to work, we have to configure the virtual and physical switches and perform other Network tasks to make the routable.so... what is the purpose of Fixed and Floating range?
The other question is that why is it that Neutron networking no longer needs these parameters?
Comments
NEGHTEDARI, big questions. The biggest difference is Neutron vs Nova. We had those configurations when DevStack was using Nova, because Nova is not dynamic. As a flat name-space you can have internal facing and external facing ips. Either or both can be assinged to a VM. You would do so by going to the instances tab, and using a drop down to assing or release IPs for that VM. Nova and or Neutron commands can be used as well if you prefer to us the CLI.
The idea of Neutron as a software defined netework is to provide flexability. We can wire-once and deploy many. The flexability comes at a price of complexity. As far as where the ips are coming from it now is configured from a neutron.conf file and is easier to generate and assign after the fact. The idea is the host IP is not necessary because we are not using NAT to get to the host, but a flexible service that uses OVS and OpenFlow to get the packets to the correct VM.
I think I touched on your questions. Let me know if I missed anything or I can point you toward more details.