Deleting VM with 'az vm delete' does not delete its disk

[kristian-lange-tw]

If I delete a VM with az vm delete I expect all dependent resources to be deleted too. But disks are not.

E.g. I have VM tw-001-westeurope

kristian@opossum:~$ az vm show -n tw-001-westeurope -g tw-rg-westeurope
{
  "availabilitySet": null,
  "diagnosticsProfile": null,
  "hardwareProfile": {
    "vmSize": "Basic_A1"
  },
  "id": "/subscriptions/***/resourceGroups/tw-rg-westeurope/providers/Microsoft.Compute/virtualMachines/tw-001-westeurope",
  "identity": null,
  "instanceView": null,
  "licenseType": null,
  "location": "westeurope",
  "name": "tw-001-westeurope",
  "networkProfile": {
    "networkInterfaces": [
      {
        "id": "/subscriptions/***/resourceGroups/tw-rg-westeurope/providers/Microsoft.Network/networkInterfaces/tw-001-westeuropeVMNic",
        "primary": null,
        "resourceGroup": "tw-rg-westeurope"
      }
    ]
  },
  "osProfile": {
    "adminPassword": null,
    "adminUsername": "azureuser",
    "computerName": "tw-001-westeurope",
    "customData": null,
    "linuxConfiguration": {
      "disablePasswordAuthentication": true,
      "ssh": {
        "publicKeys": [
          {
            "keyData": "***",
            "path": "/home/azureuser/.ssh/authorized_keys"
          }
        ]
      }
    },
    "secrets": [],
    "windowsConfiguration": null
  },
  "plan": null,
  "provisioningState": "Succeeded",
  "resourceGroup": "tw-rg-westeurope",
  "resources": null,
  "storageProfile": {
    "dataDisks": [],
    "imageReference": {
      "id": "/subscriptions/***/resourceGroups/tw-rg-westeurope/providers/Microsoft.Compute/images/tw-image-2017-11-13",
      "offer": null,
      "publisher": null,
      "resourceGroup": "tw-rg-westeurope",
      "sku": null,
      "version": null
    },
    "osDisk": {
      "caching": "None",
      "createOption": "FromImage",
      "diskSizeGb": 30,
      "encryptionSettings": null,
      "image": null,
      "managedDisk": {
        "id": "/subscriptions/***/resourceGroups/tw-rg-westeurope/providers/Microsoft.Compute/disks/tw-001-westeurope",
        "resourceGroup": "tw-rg-westeurope",
        "storageAccountType": "Standard_LRS"
      },
      "name": "tw-001-westeurope",
      "osType": "Linux",
      "vhd": null
    }
  },
  "tags": {},
  "type": "Microsoft.Compute/virtualMachines",
  "vmId": "abdaa320-2fef-4c22-aca1-339682f21bfd",
  "zones": null
}

and delete it with az vm delete:

kristian@opossum:~$ az vm delete -g tw-rg-westeurope -n tw-001-westeurope --yes
{
  "endTime": "2017-11-16T13:48:11.344229+00:00",
  "error": null,
  "name": "6a7b12f7-779d-4014-9794-720feb670f0f",
  "startTime": "2017-11-16T13:47:09.907105+00:00",
  "status": "Succeeded"
}

the disk that was attached to the VM is still there:

kristian@opossum:~$ az disk show -n tw-001-westeurope -g tw-rg-westeurope
{
  "creationData": {
    "createOption": "Copy",
    "imageReference": null,
    "sourceResourceId": "/subscriptions/***/resourceGroups/tw-rg-westeurope/providers/Microsoft.Compute/snapshots/tw-image-2017-11-13_envfb1jz4qg",
    "sourceUri": null,
    "storageAccountId": null
  },
  "diskSizeGb": 30,
  "encryptionSettings": null,
  "id": "/subscriptions/***/resourceGroups/tw-rg-westeurope/providers/Microsoft.Compute/disks/tw-001-westeurope",
  "location": "westeurope",
  "managedBy": null,
  "name": "tw-001-westeurope",
  "osType": "Linux",
  "provisioningState": "Succeeded",
  "resourceGroup": "tw-rg-westeurope",
  "sku": {
    "name": "Standard_LRS",
    "tier": "Standard"
  },
  "tags": {},
  "timeCreated": "2017-11-16T12:28:51.081460+00:00",
  "type": "Microsoft.Compute/disks",
  "zones": null
}

---

Environment summary

Install Method (e.g. pip, interactive script, apt-get, Docker, MSI, edge build) / CLI version (az --version) / OS version / Shell Type (e.g. bash, cmd.exe, Bash on Windows)

azure-cli (2.0.20)

acr (2.0.14)
acs (2.0.18)
appservice (0.1.19)
backup (1.0.2)
batch (3.1.6)
batchai (0.1.2)
billing (0.1.6)
cdn (0.0.10)
cloud (2.0.9)
cognitiveservices (0.1.9)
command-modules-nspkg (2.0.1)
component (2.0.8)
configure (2.0.12)
consumption (0.1.6)
container (0.1.12)
core (2.0.20)
cosmosdb (0.1.14)
dla (0.0.13)
dls (0.0.16)
eventgrid (0.1.5)
extension (0.0.5)
feedback (2.0.6)
find (0.2.7)
interactive (0.3.11)
iot (0.1.13)
keyvault (2.0.13)
lab (0.0.12)
monitor (0.0.11)
network (2.0.17)
nspkg (3.0.1)
profile (2.0.15)
rdbms (0.0.8)
redis (0.2.10)
resource (2.0.17)
role (2.0.14)
servicefabric (0.0.5)
sql (2.0.14)
storage (2.0.18)
vm (2.0.17)

Python location '/opt/az/bin/python3'
Extensions directory '/home/kristian/.azure/cliextensions'

Python (Linux) 3.6.1 (default, Oct 18 2017, 20:41:18) 
[GCC 4.8.4]

[yugangw-msft]

This is a reasonable ask, which i have hoped the compute service can expose such support. Note, deleting the os disk along with the VM might not always work out for users, particularly when disk is meant to be backed up so to recreate a fresh new vm later. Nevertheless, we should have such option there

[anhvoms]

I would like to see this provided as an option as well. The old "azure" cli did have a '-b' option to take care of the disk, but it's not available for az cli. It would be nice to have an option to clean up all the resources the VM is using when the VM is deleted (for example: nic, disk).

[johnggilmartin]

Indeed, at time of writing, one might say that by saying 'This will permanently delete the selected virtual machines and their related resources.' the Azure web console indicates that it will delete the disk too. (But I agree, it does not - I too have tested it.)

The above is displayed when selecting the VM and clicking the Delete button from the top button bar, but not when clicking the Delete option from the three dots 'context menu' which appears next to the VM when displaying VMs in the console. The latter way, it displays a different message simply asking for confirmation to delete the VM - no mention of selected or related resources. (Surely these ought to be consistent and behave identically?)

Edit: Looks like network interfaces remain after a VM is deleted too.

[paulpal1]

I would also like this feature.

[AndreasLangberg]

100%. This is a huge issue for any kind of automated process when you have to manually go in and clean up after the VMs all the time.

[yugangw-msft]

@adewaleo, I suggest we provide

1. -b to take care of the os disk and data disk
2. -i to take care of the public ip

[tjprescott]

When you create a VM using --tags, all tags are propagated to any other created resources. So, one could clean up these resources by querying all resources with that VM's tag and deleting them.

Instead of adding special-case arguments to vm delete, I would recommend adding client-side filters to the resource delete command.

[adewaleo]

@tjprescott @yugangw-msft. We can possibly document the tags approach somewhere to let users know this is a viable option. Perhaps here.

But given the customer demand and that CLI 1.0 did expose an option for deleting disks. I think it won't hurt to add such options as a convenience.

[tjprescott]

Deleting just the disk would not address the customer asks:

I expect all dependent resources to be deleted too.

It would be nice to have an option to clean up all the resources the VM is using when the VM is deleted

100%. This is a huge issue for any kind of automated process when you have to manually go in and clean up after the VMs all the time.

Deleting all resources based on a tag would accomplish this (unless it was impossible). Additionally, it would provide generally useful utility instead of narrow, limited utility.

[adewaleo]

That's fair. I can add some help text and examples suggesting that a user use the az resource delete --tag approach instead. Again I think it would be helpful to add it into the protips doc.

Edit:

What do we think of exposing a --tag field in az vm delete which essentially copies the behavior of az resource delete --tag, as a convenience. This would be the closes the command could actually get to deleting all related vm resources.

[tjprescott]

No, there currently isn't a --tag filter on resource delete. I'm saying we should add it.

[tjprescott]

Though a better approach might be a delete_command template that adds filters to all delete commands, similar to wait_command and show_command. However, if I ran az vm delete --tag foo=bar I would expect ONLY VMs to be deleted, not other resources.

[adewaleo]

Created #8532 to provide a work around to this issue.

[yugangw-msft]

I like the idea of az resource delete --tags! We should definitely do it. The reason I recommended extra flags to delete the disk and public ip are based on a few facts:

1. Very very few users are using --tags with az vm create.
2. Tags are used to mark a fleet of resources, not an individual resources, so using --tags targets more to removing a few virtual machines, say all created for the financial department, instead of a specific one.
3. Disk and Public IP are the 2 main things should be cleaned up. Deleting vnet, subnet might not be users' preference as doing that likely fails anyway as there are other resources in the same subnet/vnet

[jpluscplusm]

3. Disk and Public IP are the 2 main things should be cleaned up

I think one could reasonably add the NIC and automatically created NSG (the one created if no --nsg param is given when creating the VM) to that list.

[jpluscplusm]

As a new user of the az CLI, the number of disks I just found after iterating on a vm create; test; vm delete cycle was extremely surprising! Please implement something to help in this space! :-)

[adewaleo]

@jpluscplusm, hopefully #8532 will help with this!

[adewaleo]

For now, here is a work around you can try out:

• Create a vm with the desired tag. Please ensure this tag is unique (e.g mydebvm-resources)

  
  az vm create -n mydebvm -g test-vm-delete --data-disk-sizes-gb 1 1 --image debian --tags for_test=True

{ "fqdns": "", "id": "/subscriptions/00000/resourceGroups/test-vm-delete/providers/Microsoft.Compute/virtualMachines/mydebvm", "location": "westus", "macAddress": "00-00-00", "powerState": "VM running", "privateIpAddress": "10.0.0.5", "publicIpAddress": "0.0.0.0, "resourceGroup": "test-vm-delete", "zones": "" }

* Note that the tags are applied to every resource created by `az vm create`. 
> Number of lines are equal; all resources in the group have the tag.

az resource list -g test-vm-delete -otable az resource list --tag for_test=True -otable ... az resource list --tag for_test=True -otable | wc -l 13 az resource list -g test-vm-delete -otable | wc -l 13

* Delete the resources by using the ids of resources that have the **specified tag**. Again please ensure that **this tag is unique to your vm** and its associated resources. To be safe you can preprocess the ids and remove any that isn't in the expected resource group.

az resource delete --ids $(az resource list --tag for_test=True -otable --query "[].id" -otsv)

**or**

az resource list --tag for_test=True -otable --query "[].id" -otsv > delete_ids.txt az resource delete --ids $(delete_ids.txt)

(Or with a batch / bash / powershell script of your choosing)

[t-my]

Could we have an optional parameter in ARM template that signifies if the disks will be deleted or not. Much like cascade rule on databases.

[adewaleo]

I am no longer on the CLI team. Hmm, the CLI is a client of ARM / Compute, I think this would need to be a feature request to the Azure Compute Service.

Edit: However on the CLI side we could think about exposing a flag on delete that deletes any disks that were created with the vm / through vm create.

cc: @qwordy @yonzhan

Do you think you could follow up on this issue?

[qwordy]

I am no longer on the CLI team. Hmm, the CLI is a client of ARM / Compute, I think this would need to be a feature request to the Azure Compute Service.

cc: @qwordy @yonzhan

Do you think you could follow up on this issue?

Sure. I'll look into it after holiday (1st Oct ~ 7th Oct).

[yungezz]

agree with @tjprescott , user problem is to cleanup all resources created with vm, a good solution is to delete all resources via filtering tags, by supporting az resource delete --tag.

duplicate with issue https://github.com/Azure/azure-cli/issues/8532

[CraigRubendall]

I'm running into an issue with the proposed workaround of using az resource delete --tag.

It seems the use of the --tag option is not compatible with either the --resource-group option nor having a location set. That seems to make the request a lot more risky than I had hoped.

Am I missing some capability or is this the way it works? It still is not very user friendly to have to use a different api (az resource) to delete the resources that were created automatically for you as part of az vm create.

[jantari]

@CraigRubendall I use:

az resource list -g MyResourceGroup --query "[?tags.id=='$AZURE_RESOURCE_TAG'].id" --output=tsv

and it works perfectly

[sean-t-shen]

the delete of OS disk along with the VM should be offered as an option. What I want to give my client is a script that they can execute with their permission set to drop and recreate the VM. I need to give them the permission to drop the VM, but I dont want to give them the permission to drop disk as a separate permission item. If the option is there to delete the OS disk (and even all other disks attached to the VM), then I suppose I don't have to give them a separate permission to execute the deletion of disks. IMHO.

[sean-t-shen]

I tried to use the ephemeral OS disk as the workaround, but unfortunately, this is not supported for the machine size I am choosing. However, this may be an option for some other folks here....

For me, I needed to choose Standard_D4_v4 as my machine size due to another silly Azure limitation (this is the machine size that can help me avoid having to have a D: drive as Temporary Storage.). It seems most other machine sizes all come with a D drive "generously", but for my requirement I can't have that. And then related to this, when I tried to do ephemeral OS disk with my machine size, Azure tells me it is not supported for Standard_D4_v4.... I am shut out from both ends.... 👎

[mloskot]

Until the az vm delete has been improved, I resort to deleting VM with OS disk using a trivial PowerShell

$osDisk = (az vm show --resource-group MyRG --name MyVM --query "storageProfile.osDisk.name" --output tsv)

az vm delete --resource-group MyRG --name MyVM --yes

if ($osDisk) {
  az disk delete --resource-group MyRG --name $osDisk --yes
}

[sean-t-shen]

Nice. Thanks. I like this included in an “if” clause….and I like the combination of regular command shell together with Powershell to enable easy manipulation of variables and control clauses.

However, still, this would have been no issue if we are running this as a cloud admin with sufficient privileges…. My problem is, I need this to be a repeatable task given out to somebody who needs self-service capability…so I suppose I need to create a custom role for him to create/drop/start/deallocate/stop the VM, normally, that would have been the end of it. But with the OS disk not auto deleted, then I have to include one more privilege in my custom role to drop the disk. That is why I suggest the dropping of the os disk along with the dropping of the VM, as an option (or even as a default behavior….how often do we need the preserve the OS disk when the VM itself is dropped? :-) )

From: Mateusz Łoskot @.> Sent: Tuesday, April 20, 2021 11:22 AM To: Azure/azure-cli @.> Cc: Shen, Sean @.>; Comment @.> Subject: EXTERNAL EMAIL - USE CAUTION Re: [Azure/azure-cli] Deleting VM with 'az vm delete' does not delete its disk (#4897)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

I delete VM with OS disk with this trivial PowerShell

$osDisk = (az vm show --resource-group MyRG --name MyVM --query "storageProfile.osDisk.name" --output tsv)

az vm delete --resource-group MyRG --name MyVM --yes

if ($osDisk) {

az disk delete --resource-group MyRG --name $osDisk --yes

}

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/Azure/azure-cli/issues/4897*issuecomment-823362035__;Iw!!OnbYIJ6QcFHw!YxAyuQqYI0T0mer7uh99XqAtHMhLN-svXeWNCrWmSQJtOP2PLbq2Bo55RbgeA8x-$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ARFVLORLOX2ZNJTDG4JTQZ3TJWLX5ANCNFSM4EECF5NA__;!!OnbYIJ6QcFHw!YxAyuQqYI0T0mer7uh99XqAtHMhLN-svXeWNCrWmSQJtOP2PLbq2Bo55RVxpwWMT$.