VM completely down, cannot start

Question

Nic Configuration With DetachOption Cannot Reference A Subnet In Another Subscription Message: Detach DeleteOption is not supported because Network Interface Configuration XXXXXX is referencing subnet default from a Virtual Network which belongs to a different subscription

Answer 1

Hello @Han Cicimen ,

Hey Han, it looks like Azure is rejecting your VM’s network‐profile update because it thinks your NIC is pointing at a subnet in a different subscription – which of course you say isn’t true. In my experience this kind of error usually means there’s a stale or mismatched networkProfile on the VM that the Compute RP can’t reconcile. Here’s what you can try:

1. Verify subscription alignment • Make sure the VM, the NIC resource, and the VNet/subnet all live in the same subscription. • If you deliberately moved any of these between subscriptions, you’ll need to use Azure’s “Move resources” workflow so that they truly share the same subscription.
2. Inspect and correct the NIC deleteOption • Run: az vm show \

   --resource-group MyResourceGroup \
   
   --name MyVmName \
   
   --query "properties.networkProfile.networkInterfaces"
   

   • Look at the deleteOption on each network interface configuration. If it’s set to Detach, switch it to Delete (or remove the property) by running: az vm update \

   --resource-group MyResourceGroup \
   
   --name MyVmName \
   
   --set properties.networkProfile.networkInterfaces[0].properties.deleteOption=Delete
   

3. Reapply the VM provisioning state • In the portal, go to your VM > Help + support > Redeploy + reapply > Reapply. • Or use CLI: az vm reapply \

   --resource-group MyResourceGroup \
   
   --name MyVmName  
   

   This forces Azure to reload the NIC configuration and clear any stale references.
4. Detach and reattach the NIC (if the VM is deallocated) • Stop/deallocate the VM • Go to Networking > Detach the problematic NIC • Re-attach it via Networking > Add network interface • Start the VM again

If none of that works, it could be a backend sync issue. In that case, please share:

• The subscription IDs for the VM, NIC, and VNet

• The output of your az vm show … --query properties.networkProfile.networkInterfaces (JSON snippet)

• Any Activity Log errors around the time you tried to start the VM

With that info we can drill in further. Hope this helps!

Reference docs

• Resolve VM startup issues: https://docs.microsoft.com/azure/virtual-machines/states-billing#cannot-stop-start-or-restart-a-vm

• Redeploy + Reapply VM state: https://learn.microsoft.com/troubleshoot/azure/virtual-machines/windows/restart-resize-error-troubleshooting#issue-error-when-you-stop-start-restart-or-redeploy-an-existing-vm

• Move resources between subscriptions: https://docs.microsoft.com/azure/azure-resource-manager/management/move-support-resources

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

Answer 2

Hello @Han Cicimen,

To resolve this issue, you need to ensure that the NIC is not associated with any resources in the other subscription. You can use diagnostic commands to identify any blocking resources that may be preventing the operation. For example, you can check for any IP configurations associated with the subnet by using the Azure CLI command:

az network vnet subnet show --resource-group <resource-group> --vnet-name <vnet-name> --name <subnet-name> --query "ipConfigurations[].id" --output tsv

If there are orphaned NICs or other resources that are still linked to the subnet, you will need to remove them before you can detach the NIC. Additionally, ensure that there are no service endpoints or delegations that could be causing the conflict

Troubleshoot subnet modification failures

---

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Answer 3

The error indicates that the VM’s network interface configuration is set with deleteOption = Detach, but that NIC is attached to a subnet in a virtual network that resides in a different subscription. This combination is not supported, and it prevents the VM from starting.

To resolve the issue, adjust the NIC/VM configuration so that the NIC is not using Detach in this cross‑subscription scenario, or move the NIC/subnet so they are in the same subscription. In practice, this typically means:

1. Ensure the VM and its NIC are in the same subscription as the target subnet and virtual network.
2. If the NIC is orphaned or misconfigured, detach or delete it and recreate a new NIC in the correct subnet:
   • Stop and deallocate the VM.
   • Detach the problematic NIC from the VM.
   • Create a new NIC in a subnet that belongs to the same subscription as the VM.
   • Attach the new NIC to the VM and start the VM.
3. When defining or updating the VM’s network profile (for example via ARM/Bicep/SDK), set the NIC configuration’s deleteOption to a supported value for the scenario (for cross‑subscription networking, avoid Detach and use Delete or keep all resources in one subscription).

If the NIC is still attached to a VM and cannot be removed in the portal, use the documented process to remove a NIC from a VM (stop/deallocate, then detach) and then delete or recreate the NIC as needed.

---

References:

• Add network interfaces to or remove network interfaces from virtual machines
• VirtualMachineNetworkInterfaceConfigurationProperties interface