@Siddharth Joshi Greetings!
I'm using Azure ML workspace with a virtual network, private endpoints enabled and it's behind firewall So when I tried to create a "compute instance" with 1 node it gives me "Provisioning error: Desired number of dedicated nodes could not be allocated" then I have created new subnet and then I was able to provide it.
There could be several reasons for the error message "Provisioning error: Desired number of dedicated nodes could not be allocated" when trying to create a compute instance with 1 node in your existing subnet.
One possible reason could be that the subnet you were trying to use already had other resources deployed in it that were consuming the available IP addresses.
Another possible reason could be that there were not enough resources available in the region to allocate the desired number of nodes. In this case, creating a new subnet may have helped because it provided additional resources that were not being used by other resources in your workspace.
It's also worth noting that when you create a compute instance in a workspace with a private endpoint, the compute instance and compute cluster must be in the same Azure region as the workspace.
I wanted to know why it's giving me an error with the existing subnet even though around 222 IPs are free and I know that azure reserves only 5 IPs from each subnet still 218 IPs will leave.
The number of IP addresses required to provision a Compute Instance in Azure ML workspace depends on the number of nodes you want to allocate for the Compute Instance. Each node in a Compute Instance requires a dedicated IP address.
As you mentioned, Azure reserves some IP addresses for its own use, such as the first and last IP addresses in each subnet. Additionally, if you have other resources deployed in the same subnet, they may be using some of the available IP addresses.
Is there any reason behind it?
Please note that We do not recommend using the 172.17.0.0/16 IP address range for your VNet. This is the default subnet range used by the Docker bridge network. Other ranges may also conflict depending on what you want to connect to the virtual network. For example, if you plan to connect your on premises network to the VNet, and your on-premises network also uses the 172.16.0.0/16 range. Ultimately, it is up to you to plan your network infrastructure.
Also, please check the Limitations when Configuring a private endpoint for an Azure Machine Learning workspace
I hope this helps. Please let us know if you have any further questions or concerns.