Terraform azurerm_managed_disk每次apply重建连带VM销毁问题

• 直接触发重建的核心原因：azurerm_managed_disk资源配置缺失强制不可变属性的显式声明。从plan输出带*# forces replacement*标记的日志可以看到，hyper_v_generation属性在Terraform状态中存储了Azure环境自动回填的"V1"值，但配置中未声明该参数，Terraform会将未声明参数的预期值判定为null，而该属性为磁盘创建后不可修改的强制参数，值发生变更时必须销毁重建磁盘。
• 首次部署可正常执行的原因：初始状态文件无该资源的属性记录，创建磁盘时Azure自动补全hyper_v_generation="V1"、os_type="Windows"、trusted_launch_enabled=false等默认值并写入状态；后续执行plan时，配置中未声明这些参数导致预期值为null，与状态中存储的实际值产生漂移，触发重建逻辑。
• 次要配置冲突：azurerm_virtual_machine的storage_os_disk块重复声明了已由独立azurerm_managed_disk资源管控的磁盘规格参数（disk_size_gb、managed_disk_type），两个Terraform资源同时管控同一个Azure磁盘对象，会进一步放大属性漂移问题，磁盘重建时会连带触发挂载它的虚拟机重建。

• 第一步优先定位plan输出中带*# forces replacement*标记的属性行，直接锁定触发强制重建的核心变更项，本次问题的核心触发项就是hyper_v_generation从"V1"变为null。
• 对比配置与状态文件的属性差异：所有日志中标记为- 属性名 = 实际值 -> null的项，均为配置未显式声明、Azure资源创建后自动回填的属性，属于预期值缺失导致的配置漂移。
• 检查资源管控权归属：确认同一个Azure资源是否被多个Terraform资源块重复声明管控，本问题中OS磁盘同时被独立的azurerm_managed_disk资源和虚拟机的storage_os_disk块管控，属于典型的资源权限冲突。

1. 补全azurerm_managed_disk资源中缺失的显式属性声明，与Azure实际运行值保持一致，修改后配置如下：

resource "azurerm_managed_disk" "zerto_managed_disk" {
  name                 = "az1srzerto_managed_disk"
  location             = azurerm_resource_group.resource_group.location
  resource_group_name  = azurerm_resource_group.resource_group.name
  storage_account_type = "Standard_LRS"
  create_option        = "Copy"
  source_resource_id   = azurerm_snapshot.snapshot.id
  disk_size_gb         = "127"
  # 补全Azure自动回填的不可变属性
  os_type              = "Windows"
  hyper_v_generation   = "V1"
  # 显式声明tags避免空值漂移，无标签则设为空map
  tags                 = {}
}

2. 调整虚拟机storage_os_disk块的配置，删除重复管控磁盘规格的参数，仅保留挂载外置磁盘所需的必要字段，避免两个资源争抢管控权，修改后配置如下：

storage_os_disk {
  name            = azurerm_managed_disk.zerto_managed_disk.name
  caching         = "ReadWrite"
  os_type         = "Windows"
  managed_disk_id = azurerm_managed_disk.zerto_managed_disk.id
  create_option   = "Attach"
  # 删除原配置中的disk_size_gb、managed_disk_type字段，这两个字段由独立的azurerm_managed_disk资源统一管控
}

3. 配置修改完成后，先执行terraform refresh同步Azure侧最新的资源属性到本地状态文件，再执行terraform plan确认输出中不再有-/+ destroy and then create replacement的重建标记，确认无误后再执行apply即可。

内容的提问来源于stack exchange，提问作者cz75ww