Search code examples
sql-serverazureterraformazure-pipelinesazure-rm

Error with storage when using NEW disk type in Terraform SQL Server virtual machine setup

I'm trying to add the SQL Server "data"/ "log" disk by using Terraform. There are 3 data disk created for the VM with luns 0,1,2 each set to Standard SSD with 128G of space in Terraform enter image description here

The following snippet is what I am currently trying to run.

resource "azurerm_mssql_virtual_machine" "sqlconfig" {

  virtual_machine_id               = azurerm_windows_virtual_machine.vm[var.HOSTNAME_MICROSOFTSQL].id
  sql_license_type                 = "PAYG"
  sql_connectivity_port            = *redacted 
  sql_connectivity_type            = *redacted 
  sql_connectivity_update_password = *redacted 
  sql_connectivity_update_username = *redacted 

  sql_instance {

    collation = "SQL_Latin1_General_CP1_CI_AS"

  }

  storage_configuration {

    disk_type = "NEW" 
    storage_workload_type = "OLTP"
  
    data_settings {

      default_file_path = "F:\\Data"
      luns = [0]

    }

    log_settings {

      default_file_path = "G:\\Log"
      luns = [1]

    }

    temp_db_settings {

      default_file_path = "G:\\tempDb"
      luns = [1]
      data_file_count = 8
      data_file_size_mb = 8
      data_file_growth_in_mb = 64
      log_file_size_mb = 8
      log_file_growth_mb = 64

    }

  }

However, I am getting the following error when deploying from azure devops pipeline

 polling after CreateOrUpdate: Code="Ext_StorageConfigurationSettingsError" Message="Error: 'Number of disks found do not match the expected count for creating Storage Pool, found :0 target: 1. Detail: Disk with LUN number 0 cannot be pooled. Reason : Insufficient Capacity'"

What does this error mean?

Solution

  • It appears that within Terraform, when creating the Datadisks and attaching them to the VM before running the section on azurerm_mssql_virtual_machine, it runs into some kind race condition between setting up the disk/attachment and storage configuration within azurerm_mssql_virtual_machine. This problem is solved once we added the following block of code under azurerm_mssql_virtual_machine:

        depends_on = [
          azurerm_virtual_machine_data_disk_attachment.[disk_attachment_name]
    ]