Ask Your Question

How to stop quantum assigning IP for the port

asked 2013-05-23 17:17:52 -0500

wei-wen-chen gravatar image

The setup if for flat network where there is external DHCP server in my data center so all VMs should grab an IP from outside, instead of quantum assigning one automatically for each VM port. enable_dhcp flag has no effect. At port creation, an IP is always assigned. How to stop quantum assign IP for port?

edit retag flag offensive close merge delete

3 answers

Sort by ยป oldest newest most voted

answered 2013-05-24 10:36:07 -0500

gongysh gravatar image

If u don't want quantum to assign IPs, you should not use quantum at all. why not just create a network API which just return NULL networks?

edit flag offensive delete link more

answered 2013-06-12 22:44:13 -0500

ryan-tidwell gravatar image

The reality is that a lot of enterprises have existing infrastructure that they want to selectively plumb into quantum. On any given provider network or flat network I may only want Quantum to give me L2 connectivity and turn over the IPAM to an existing DHCP server. It doesn't look to me like that is something easily supported by Quantum, particularly by the OVS plugin. This is not an off-the-wall question, I am hearing people wanting to support this use case in their private cloud. In this scenario, things like security groups may be harder to enforce since Quantum may not know the IP address that is handed out by the external DHCP server. There may be some challenges to building in support for this use case, but let's not dismiss it. Saying "you should not use quantum at all" seems a little over-the-top.

edit flag offensive delete link more

answered 2014-01-21 10:45:19 -0500

marek-ruzicka gravatar image

Is there any follow up on this? I fully agree with Ryan here... The way I would expect this to work is, either be able to create a network without subnet, and plug the VM to it. I would expect quantum to provide only L2, and do not try to enforce any security group related stuff. Or basically the same stuff but with subnet with DHCP disabled. I would prefer the first option, since subnet requires allocation pool to be defined, which might introduce unnecessary confusion, since I don't want quantum to handle IPs in any way..

This IMHO makes great sense with provider networks (not exclusively) , since I really don't see a point for quantum to mess around with IPs when I'm trying to map/link virtual network to a physical one (where supposedly other services like DHCP/DNS are already running).

Another use case I have is when we are using openstack as a training environment. Of course there are limited resources in such cloud, so we ask the users to create snapshot and delete all their VMs once they are finished with trainings/testing. Problem is, that if they have any kind of static network configuration (for whatever reason - it is a training/testing env.) and they boot up the snapshot later, it simply does not work, since they have been most likely assigned new IP (even though their static network settings matched the pre-assigned IP from the time of first boot).

We have circumvent this by a very dirty hack, where we just disabled the antispoof protection for the source IP (MAC is still enforced), but as you might see, IP is still assigned and shown in eg. horizon, just not enforced.

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2013-05-23 17:17:52 -0500

Seen: 94 times

Last updated: Jan 21 '14