TritonDataCenter
Unable to set static IP when adding external NIC to adminui0 imgapi0
When adding a New NIC to a service VM, it is unable to specify a static IP.
Also, it does not take an available IP address. Instead, it incrementally assigns the next IP in the pool.
@naisanza Agreed that you should be able to explicitly request the IP that you use when adding a NIC in adminui.
Regarding the IP selection, it's not defined to take it and use them in any particular order. In this case, the reason you're seeing this comes down to how NAPI defines its queries. See https://github.com/joyent/sdc-napi/blob/master/lib/models/ip/provision.js#L25 for more information.
@rmustacc "Try to find a free IP that has never been used before" is exactly how it works. Since none of the IP's in the pool have been used before, it appears to assign one incrementally. Not a big deal, until we can assign static IPs, I'll just need to restrict the IP range to n and n+1; n, being the expected IP I'd like assigned to the new VM.
Also, when assigning a NIC, there is not a check to make sure the IP is not already in use (e.g. an IP that has been statically assigned to a physical server on the same subnet that falls within the provisioning range). I think a quick ping before assigning an IP could be beneficial in avoiding addressing conflicts; causing both servers to lose connectivity
In your latter case does this mean that there are things using the addresses that SDC isn't using? If so, then they should be marked reserved by the operator. Unfortunately there's a bit of a chicken and egg problem with what you'd like. Until you create a machine, we actually do the provision, there's no VNIC that necessarily exists in the system where one can appropriately do the ping from.
If there are conflicts, we should certainly do a better job about notifying and alerting the operator that this has happened and trying to get information about whom conflicted with the IP. But the general assumption is that when you give SDC a network, anything that the operator hasn't reserved in its provisionable range is fair game.
@rmustacc correct! It is a mixed static and dhcp non-production environment. I wouldn't mind manually reserving the addresses, but the IP Address Allocation list doesn't show me all the IPs in the subnet for me to do that.
If a ping function were to be added, it could be managed and initiated from the adminui0 server, since it is (other than imgadm0) the only VM with attached NICs into the external network pools
You can use the NAPI API to take care of that in the interim. I'll open a bug against Adminui for both of these issues around IP address management that you've raised and link them here once they've been done.
Longer term, we can look at trying to do some more network probing to try and help with situations like this and allowing an operator to make decisions based on that. But it's probably going to be a fairly low priority thing at the moment.
I filed both https://smartos.org/bugview/ADMINUI-2160 and https://smartos.org/bugview/ADMINUI-2159 to cover these adminui features.
On 7/30/15 15:18 , Eric wrote:
@rmustacc I'll take a look at the NAPI API for the time being. Thanks!
Take a look at https://github.com/joyent/sdc-napi/blob/master/docs/index.md#example-reserving-an-ip, should have an example to help you out. You can use the sdc-napi command in the global zone to help you get by in the interim.
Robert
@naisanza Why not configure each with non-overlapping ranges on the same network prefix? E.g., give 10.0.1.6-10.0.1.127 to DHCP and 10.0.1.127-10.0.1.254 to SDC, or whatever ratio you think you need on either side.
@bahamat that would be ideal wouldn't it! Except I didn't have the luxury of setting up, so addresses are assigned randomly, and picked up by anyone who decides to use one. Which means I need a pre-start script to check if an address is being used before starting or creating a VM.
This issue crossed over into joyent/sdc-adminui and was addressed by both PR #153 and PR #102. Fairly certain this can be closed but going to wait on confirmation from @naisanza that this is resolved or isn't on his radar anymore.
