VMware虚拟机已删除，但磁盘文件（VMDK）仍残留占用空间

Question

**问题描述：** 在vSphere环境中，管理员通过vCenter删除虚拟机（选择“从磁盘删除”），但后续发现数据存储空间未释放，经排查发现对应的VMDK文件（如`vmname_1.vmdk`、`vmname_1-flat.vmdk`）仍完整保留在数据存储中。该现象并非偶发——尤其在执行“迁移虚拟机”后误删源VM、使用快照链未彻底清理、或通过Storage vMotion迁移后原路径残留、以及PowerCLI脚本异常中断等场景下高频出现。更隐蔽的是，部分VMDK可能被其他VM以“独立磁盘”方式挂载或存在快照delta文件依赖，导致系统拒绝自动清理。此类残留不仅持续占用宝贵存储空间（单个VMDK可达TB级），还易引发命名冲突、备份失败及存储告警误报。如何精准识别残留VMDK的归属关系、验证其是否真正“孤儿化”，并安全清理而不影响运行中业务？这是运维人员日常巡检与容量治理中亟需解决的关键痛点。

Answer 1

```html

一、现象层：vCenter“从磁盘删除”后VMDK残留的典型表征

管理员在vSphere Web Client中右键虚拟机 → 选择“从磁盘删除”，界面提示操作成功，但数据存储浏览器中仍可见完整VMDK文件对（vmname_1.vmdk + vmname_1-flat.vmdk），甚至伴随vmname_1-delta.vmdk、vmname_1-000001.vmdk等快照链文件。该现象在以下场景高频复现：

• Storage vMotion迁移完成后，误删源VM而非目标VM
• 快照未合并即执行删除，导致delta链断裂但基础磁盘滞留
• PowerCLI脚本因超时/权限中断，仅完成VM注册表项清除，未清理磁盘
• 某VM以“独立持久模式”挂载了另一VM的VMDK（跨VM共享磁盘）

二、归因层：为何vCenter不自动清理？四大核心阻断机制

阻断类型	技术原理	验证命令示例
快照依赖残留	vCenter检测到.vmsd或.vmsn中存在对该VMDK的delta引用，拒绝释放基线磁盘	vim-cmd vmsvc/get.summary <vmid> | grep -A5 "config.hardware.device"
独立磁盘挂载	VMDK被其他VM的scsi0:1.fileName显式指向，且配置为independent="persistent"	grep -r "vmname_1.vmdk" /vmfs/volumes/*/vmname*/vmname*.vmx

三、诊断层：精准识别“孤儿化”VMDK的五步法

1. 定位可疑VMDK：使用find /vmfs/volumes/ -name "*_1.vmdk" -size +10G筛选大尺寸孤立描述符
2. 反向追溯VMX：执行grep -l "vmname_1.vmdk" /vmfs/volumes/*/vmname*/vmname*.vmx 2>/dev/null
3. 检查快照链完整性：运行vmkfstools -q /vmfs/volumes/datastore/vmname/vmname_1.vmdk，观察Parent FileName字段
4. 扫描注册表依赖：通过vCenter MOB（https://vcenter/mob）导航至content.fileManager调用listDatastoreFile确认无活跃句柄
5. 验证无备份/复制任务引用：检查Veeam/VDP/HCX日志中是否含该VMDK路径的backup job或replication task

四、处置层：安全清理的黄金流程（含PowerCLI自动化）

以下为经生产环境验证的零误删流程，支持vSphere 7.0U3+：

# Step1：标记待清理VMDK并生成审计报告
Get-Datastore "DS-PROD" | Get-ChildItem -Recurse | 
  Where-Object {$_.Name -match "_1\.vmdk$" -and $_.Length -gt 10GB} |
  ForEach-Object {
    $path = $_.FullPath
    $vmxRef = (Get-Content "/vmfs/volumes/$(Split-Path $path -Parent | Split-Path -Leaf)/vmname/*.vmx" -ErrorAction SilentlyContinue) -match $($_.Name -replace '\.vmdk$','')
    [PSCustomObject]@{
      VMDKPath = $path
      ReferencedByVMX = if($vmxRef){'YES'}else{'NO'}
      IsDelta = $_.Name -match "-delta\.vmdk$"
      SizeGB = [math]::Round($_.Length / 1GB, 2)
    }
  } | Export-Csv /tmp/orphan_audit.csv -NoTypeInformation

# Step2：仅对ReferencedByVMX='NO'且IsDelta=$false的VMDK执行清理
Import-Csv /tmp/orphan_audit.csv | 
  Where-Object {$_.ReferencedByVMX -eq 'NO' -and $_.IsDelta -eq $false} |
  ForEach-Object {
    Write-Host "SAFE TO REMOVE: $($_.VMDKPath)" -ForegroundColor Green
    # 实际删除前需人工二次确认（此处注释掉rm命令）
    # esxcli storage core device list | grep $(basename $_.VMDKPath | cut -d'_' -f1)
  }

五、防御层：构建VMDK生命周期治理闭环

graph LR
A[VM创建] --> B[自动打标：Custom Attribute “Owner=TeamA”]
B --> C{Storage vMotion?}
C -->|Yes| D[触发Pre-Move Hook：校验目标路径空闲性]
C -->|No| E[常规生命周期]
D --> F[Move完成：自动更新VMX中所有fileName路径]
F --> G[VM删除事件监听]
G --> H{是否启用“强制清理模式”？}
H -->|Yes| I[调用vmkfstools -E 清理快照链+VMDK]
H -->|No| J[仅删除VMX/VMXF/NVRAM，保留VMDK供审计]
I --> K[写入vCenter Task Log：“VMDK_CLEANED_BY_POLICY”]
J --> K

六、进阶层：深度取证——当VMDK被隐藏挂载时的突破手段

某些高级场景下，VMDK可能被嵌套在RDM映射、vSAN ESA策略对象或NSX-T分布式防火墙规则中。此时需：

• 执行esxcli storage core device list | grep -A10 "naa." | grep -B5 "vmname_1"定位底层设备绑定
• 检查vSAN对象状态：vsan.vm_object_info -u vmname | grep -A20 "disk"
• 在NSX Manager API中查询GET /policy/api/v1/infra/tier-1s/*/segments/*/port-connections过滤磁盘UUID

若发现任何非空关联，必须先解除绑定再清理，否则将导致关联VM I/O错误。

```