How to fix error "This compute instance doesn't appear to be connectable" when launching a Machine Learning Compute instance

Question

How to fix error "This compute instance doesn't appear to be connectable" when launching a Machine Learning Compute instance

ZINOVIADIS Charalampos 0

I am trying to create a Machine Learning notebook from the portal and I keep getting the error

"This compute instance doesn't appear to be connectable. Check to make sure it's started. If you just started it, please wait a little longer."

The workspace is in a private subnet, and the associated resources (storage account, container registry, keyvault) are in a different private network. Private endpoints, private dns zones and virtual links have been created.

I have also created outbound network security group rules as to AzureMachineLearning, Storage, MicrosoftContainerRegistry etc. but still it is not working.

What am I missing here?

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer accepted by question author

0 additional answers

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

The error indicates that the Azure Machine Learning service cannot establish a connection to the Jupyter/JupyterLab service running on the compute instance. In a private network setup, this is typically caused by DNS resolution failures or blocked storage mounts.

Here are the most common missing configurations based on your setup:

Missing Private DNS Zone Links for Notebooks: The compute instance must be able to resolve the workspace and notebook endpoints locally. Verify that both the privatelink.api.azureml.ms and privatelink.notebooks.azure.net private DNS zones are explicitly linked (Virtual Network Links) to the VNet where your compute instance is deployed.

Blocked Storage Account File Share (Port 445): Compute instances mount the workspace's default Azure Storage Account via SMB to access your notebook files. If the compute cannot mount this file share, it will fail to start or connect. Ensure outbound TCP Port 445 is allowed from the compute subnet to the storage account's private IP.

Storage DNS Resolution: Since your storage account is in a different private network, ensure the privatelink.file.core.windows.net and privatelink.blob.core.windows.net DNS zones are linked to the compute instance's VNet so it can resolve the storage account's private endpoint.

Missing VNet Peering: You mentioned the associated resources are in a "different private network." If these are entirely separate Virtual Networks (not just different subnets within the same VNet), you must establish two-way VNet peering between the workspace/compute VNet and the associated resources VNet.

WebSocket Traffic Blocked: Connecting to the notebook UI requires WebSockets. If you are routing outbound traffic through an Azure Firewall or a custom Network Virtual Appliance (NVA) via a User Defined Route (UDR), verify that the firewall is not stripping or blocking wss:// (WebSocket) connections