Azure Terraform联用azurerm_windows_virtual_machine与azurerm_mssql_virtual_machine的SQL存储配置问题

核心逻辑说明 #

两个新版资源的配置是完全独立的校验链路，不存在自动打通存储配置的隐式兼容逻辑，旧版文档示例未更新不是部署失败的原因，核心问题都是没有对齐两个资源之间的存储配置传递规则。

分步解决踩坑点 #

1. azurerm_windows_virtual_machine中配置数据磁盘与LUN的方式 #

直接使用资源原生支持的data_disk嵌套块即可，逻辑和旧版azurerm_virtual_machine完全一致，每个条目必须显式声明lun参数，示例片段：

resource "azurerm_windows_virtual_machine" "sql_vm" {
  # 基础配置（VM名称、规格、管理员账号、网络配置等）省略
  source_image_reference {
    publisher = "MicrosoftSQLServer"
    offer     = "sql2022-ws2022"
    sku       = "enterprise-gen2"
    version   = "latest"
  }

  # 注意：需避开OS盘、临时磁盘默认占用的LUN值，从可用LUN序号开始分配
  data_disk {
    name              = "sql-data-0"
    lun               = 2
    caching           = "ReadOnly"
    disk_size_gb      = 128
    storage_account_type = "Premium_LRS"
  }
  data_disk {
    name              = "sql-log-0"
    lun               = 3
    caching           = "ReadOnly"
    disk_size_gb      = 128
    storage_account_type = "Premium_LRS"
  }
  data_disk {
    name              = "sql-tempdb-0"
    lun               = 4
    caching           = "None"
    disk_size_gb      = 256
    storage_account_type = "Premium_LRS"
  }
}

关键注意点：这里通过data_disk块挂载的磁盘不会自动完成分区、格式化、盘符分配，必须配合CustomScriptExtension等自定义扩展，提前把所有磁盘格式化为和后续SQL配置匹配的固定盘符（比如D盘分配给数据目录、E盘分配给日志目录、F盘分配给TempDB目录），这是后续所有校验通过的必要前提。

2. 门户提示"Drive is not found in the volumes list"的解决逻辑 #

这个报错和虚拟机本身的磁盘配置无关，是azurerm_mssql_virtual_machine关联目标VM后，会自动扫描VM上已挂载的卷列表做校验，如果识别不到SQL默认路径对应的盘符，就会在SQL VM配置页弹出提示。

• 不要跳过storage_configuration块的配置，就算已经提前完成磁盘格式化，也必须显式在资源声明里告知SQL VM规划的默认文件路径，否则校验流程会一直卡在异常状态。

3. 配置storage_configuration时报"InvalidDefaultFilePath"的修复方案 #

这个报错的核心原因不是路径字符串写得不对，而是storage_configuration块中声明的LUN对应的磁盘，和实际分配的盘符、路径完全不匹配。

• 正确的配置逻辑必须和前面Windows VM的LUN分配、自定义扩展格式化的盘符严格一一对应，示例片段：

resource "azurerm_mssql_virtual_machine" "sql_association" {
  name                 = "ASQLVM"
  resource_group_name  = azurerm_resource_group.sql_rg.name
  virtual_machine_id   = azurerm_windows_virtual_machine.sql_vm.id
  sql_server_license_type = "PAYG"
  sql_image_offer      = "sql2022-ws2022"
  sql_image_sku        = "Enterprise"

  storage_configuration {
    disk_type             = "Premium_LRS"
    storage_workload_type = "GENERAL"

    data_settings {
      luns                  = [2]
      default_file_path     = "D:\\SQLData"
      default_log_path      = "E:\\SQLLog"
      default_tempdb_path   = "F:\\SQLTempDB"
    }

    temp_db_settings {
      data_file_count    = 8
      data_file_size_mb = 512
      luns              = [4]
    }
  }
}

• 高频踩坑规避：
  • 不要声明和实际盘符不匹配的路径，比如实际磁盘被格式化为F盘，配置里填了D盘路径，会直接触发InvalidDefaultFilePath报错
  • 不要给LUN分配系统盘、临时磁盘的固定占用值，避免底层磁盘挂载冲突
  • 不要在不同配置块里重复声明同一个LUN，比如data_settings和log_settings写同一个LUN序号，也会触发校验失败

部署校验顺序 #

• 先完成Windows VM的部署，等VM运行状态正常后，通过自定义脚本扩展完成所有数据磁盘的分区、格式化、盘符分配，逐一确认盘符和计划的SQL路径完全一致
• 再发起azurerm_mssql_virtual_machine资源的创建请求，确保storage_configuration内的LUN列表、路径和前面的磁盘配置完全对齐
• 部署完成后在门户检查SQL虚拟机配置页，只要参数链路完全匹配，就不会出现磁盘找不到的异常提示

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