Azure VMware Solution: Unable to Delete VM in vCenter — Permission and Lock Issues

Dean Leong 0 Reputation points
2026-09-04T08:19:50.8333333+00:00

Problem description

I am unable to delete a virtual machine named TNT59-VCENTER_upgrade_backup from my Azure VMware Solution environment. Attempts to remove the VM do not succeed, and I have not received any detailed error messages or codes. The VM remains listed in vCenter and cannot be deleted.

Environment

Azure VMware Solution private cloud, managed by VMware vCenter, in the specified region.

What I've already tried

I attempted to delete the VM via the vSphere Client's 'Delete from Disk' action, but the operation failed without providing error details. Additionally, I found no diagnostic data or logs for analysis. I also suspect that the VM was created during a system upgrade by VMware Support and may have been left behind. I cannot assign myself the administrator role as the option is greyed out, and I would like to request full admin access to remove the VM if appropriate.

Current status

The VM is still listed in vCenter and cannot be removed. I am seeking assistance to identify the cause of the deletion failure, verify permissions, check for resource locks, and determine if any background operations are preventing deletion. I would also like guidance on how to proceed with removing the VM or escalating the issue for further support.

Azure VMware Solution
0 comments No comments

1 answer

Sort by: Oldest
  1. Allan Solomon Mejia 7,915 Reputation points
    2026-09-04T19:14:04.6833333+00:00

    Hello @Dean Leong

    The VM name TNT59-VCENTER_upgrade_backup strongly suggests this may be an artifact created during a vCenter lifecycle/upgrade operation, rather than a normal customer workload VM.

    Therefore, do not attempt to bypass the permissions, alter its files directly on the datastore, or request/assign yourself full vCenter Administrator privileges at this stage.

    Azure VMware Solution uses a managed vCenter permission model. Customers normally operate with the CloudAdmin role and don't receive administrator@vsphere.local or ESXi root access because Microsoft manages the lifecycle of the SDDC management components.

    As an initial check, could you please confirm:

    • whether this VM appeared immediately after a recent AVS/vCenter maintenance or upgrade;
    • whether it is located alongside the AVS management VMs rather than your normal workload VMs;
    • whether Recent Tasks in vCenter shows a failed delete task and, if so, its details;
    • whether the VM has any active tasks, snapshots, or alarms.

    If this VM was generated by an AVS-managed vCenter upgrade and CloudAdmin cannot delete it, I recommend opening an Azure support request for Azure VMware Solution and asking Microsoft to verify whether it is a stale upgrade/backup artifact and remove it from the managed vCenter inventory if appropriate.

    Avoid manually deleting its datastore files even if you find a way to access them. If the object belongs to an AVS platform lifecycle operation, Microsoft should first verify that it is no longer required.

    Also, Azure resource locks aren't normally the first place to look here. You're attempting the operation inside vCenter, whereas Azure resource locks apply to Azure Resource Manager resources. The symptoms and VM name point more to the vCenter/AVS management plane.

    If you can share the Recent Tasks error details from the failed Delete from Disk operation and confirm whether there was recent AVS maintenance/upgrade, we can narrow this down further.

    Reference: Azure VMware Solution identity and vCenter access model

    Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.