- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ04-28-2023 03:04 AM
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ04-28-2023 03:19 AM
Hello @Amine HADJ-YOUCEFโ
โSUBNET_EXHAUSTED_FAILUREโ are because VMs on unhealthy partitions cannot be freed, so the resources and associated quota cannot be released, and you are running out of quota.
Your vnet/subnet is out of non-occupied IPs and this can be fixed by allocating more IPs to your network address space.
Each cluster requires it's own IP, so if there are none available, it simply cannot start.
- Increase the size of the subnet: You can try to expand the IP address range of the subnet by increasing the subnet mask. For example, if your subnet is currently using a /26 mask (64 IP addresses), you could increase it to a /25 mask (128 IP addresses). This will give you more IP addresses to work with.
- Create a new subnet: If expanding the current subnet is not feasible, you can create a new subnet with a larger IP address range and assign it to the NIC.
- Delete unused resources: You may want to check if there are any unused resources, such as unassigned IP addresses or idle VMs, that are taking up space in the subnet. You can remove these resources to free up IP addresses.
- Use a different IP address range: If none of the above options work, you can try using a different IP address range altogether. This will require changing the IP address ranges of all resources that are using the current subnet.
- Contact Cloud Provider Support.
Hope this helps.
Thanks & Regards,
Nandini
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ04-28-2023 03:17 AM
#DAIS2023โ i guess If your subnet is too small to accommodate all the required network interfaces, you can try increasing its size by adding more IP addresses to it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ04-28-2023 03:19 AM
Hello @Amine HADJ-YOUCEFโ
โSUBNET_EXHAUSTED_FAILUREโ are because VMs on unhealthy partitions cannot be freed, so the resources and associated quota cannot be released, and you are running out of quota.
Your vnet/subnet is out of non-occupied IPs and this can be fixed by allocating more IPs to your network address space.
Each cluster requires it's own IP, so if there are none available, it simply cannot start.
- Increase the size of the subnet: You can try to expand the IP address range of the subnet by increasing the subnet mask. For example, if your subnet is currently using a /26 mask (64 IP addresses), you could increase it to a /25 mask (128 IP addresses). This will give you more IP addresses to work with.
- Create a new subnet: If expanding the current subnet is not feasible, you can create a new subnet with a larger IP address range and assign it to the NIC.
- Delete unused resources: You may want to check if there are any unused resources, such as unassigned IP addresses or idle VMs, that are taking up space in the subnet. You can remove these resources to free up IP addresses.
- Use a different IP address range: If none of the above options work, you can try using a different IP address range altogether. This will require changing the IP address ranges of all resources that are using the current subnet.
- Contact Cloud Provider Support.
Hope this helps.
Thanks & Regards,
Nandini
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ04-28-2023 03:56 AM
Are you sure you can change the subnet size on an existing Databricks environment? I was always told that this is not possible.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ05-02-2023 02:43 AM
@Werner Stinckensโ ,
I checked again, you cannot change them after your workspace is deployed. The only way right now is to recreate the workspace and migrate. Itโs not possible to update CIDR range right now without migration.

