Add support for OS disk performance tier configuration

[devin-ai-integration]

Description

Implements support for setting OS disk performance tier during VM builds to improve disk I/O performance for disk-intensive operations.

Link to Devin run: https://app.devin.ai/sessions/7d2a23a5f78e405bb802cd69d6169718
Requested by: Jonathan Mortensen (jmomort@gmail.com) / @jmomort

What Changed

Adds a new os_disk_performance_tier configuration option that allows users to specify a higher performance tier (P1-P80) for the OS disk during builds. This improves build performance without affecting the final image size.

Key Implementation Details:

Due to Azure ARM template limitations (tier property only supported on standalone disk resources, not on VM managedDisk objects), this implementation:

1. Creates a standalone Microsoft.Compute/disks resource with the specified tier and the VM's configured storage account type
2. Creates the disk from the source image using createOption: "FromImage"
3. Attaches the disk to the VM using createOption: "Attach"
4. Uses VMAccessForLinux extension to inject SSH credentials (since Azure doesn't allow osProfile with attached disks)

Recent fixes:

• Corrected VMAccessForLinux extension settings format per Azure documentation (username and ssh_key in protectedSettings)
• Fixed hardcoded disk SKU to use VM's configured storage account type instead of hardcoded "Premium_LRS"
• Removed hardcoded Sku.Tier field (Azure infers it from Sku.Name)

Limitations:

• Only supported with Shared Image Gallery or Managed Image sources (marketplace images not supported)
• Requires managed_image_storage_account_type to be set to Premium_LRS (validated at config time)
• Not compatible with disk_encryption_set_id (validation prevents this combination)
• Currently Linux-only (uses VMAccessForLinux extension)

Files Changed

Core Implementation:

• builder/azure/arm/config.go: Added field, validation for 14 valid tiers (P1-P80), restrictions for marketplace/encryption, Premium_LRS requirement
• builder/azure/arm/template_factory.go: Integrated into VM template creation flow
• builder/azure/common/template/template_builder.go: Implemented disk creation + extension logic with storage account type from VM config
• builder/azure/common/template/template.go: Added disk-specific structs and fields

Tests:

• builder/azure/arm/config_test.go: Validation tests for valid/invalid tiers
• builder/azure/common/template/template_builder_test.go: Template generation approval test
• All 45 approval test files updated with new diskApiVersion variable

Generated Files:

• builder/azure/arm/config.hcl2spec.go: HCL2 support (auto-generated)
• docs-partials/builder/azure/arm/Config-not-required.mdx: Documentation (auto-generated)

Resolved Issues

Closes hashicorp#548

Rollback Plan

If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Credential Injection Change: This PR changes how SSH credentials are provided to the VM when using OS disk performance tier:

• Previous approach (normal builds): Credentials in osProfile during VM creation
• New approach (with tier): Credentials injected via VMAccessForLinux extension after VM boots

The extension uses Azure's protectedSettings mechanism to securely transmit credentials (username and SSH key are encrypted in transit and not exposed in ARM template logs).

Human Review Checklist

⚠️ Critical - Needs Real Azure Testing:

1. VMAccessForLinux Extension Config: The extension settings format was corrected in the final commits based on Azure documentation but hasn't been tested with a real deployment yet. Previous versions failed with various Azure API errors. Current config uses:

   "protectedSettings": {
     "username": "[parameters('adminUsername')]",
     "ssh_key": "--test-ssh-authorized-key--"
   }

   With no public settings field. This needs to be verified with an actual Packer build against Azure.

2. Storage Account Type Requirement: The implementation now correctly uses the VM's configured storage account type for the disk SKU and validates that it must be Premium_LRS. However, users might not realize they need to explicitly set managed_image_storage_account_type: "Premium_LRS" in their config. Is the error message clear enough?

3. Windows Compatibility: This implementation uses VMAccessForLinux extension. Does this break Windows builds? Should this feature be:

   • Gated to Linux-only with explicit validation?
   • Extended to support Windows with WinRM extension?
   • Documented as Linux-only?

4. Error Handling: What happens if the VMAccessForLinux extension fails to provision? Will Packer detect this and fail the build gracefully, or will it hang trying to SSH?

5. API Version Split: Verify that using separate API versions for disks (2023-04-02) and VMs (2023-03-01) is acceptable and won't cause future maintenance issues.

6. Disk Creation from SIG: The disk is created with createOption: "FromImage" and galleryImageReference. Verify this is the correct way to create a disk from a Shared Image Gallery image (not just marketplace images).

7. Security Review: Validate that using VMAccessForLinux extension for credential injection (instead of osProfile) doesn't introduce any security concerns or edge cases.

Example Usage

source "azure-arm" "example" {
  custom_managed_image_name                = "my-base-image"
  custom_managed_image_resource_group_name = "my-rg"
  managed_image_storage_account_type       = "Premium_LRS"  # Required for performance tier
  os_disk_performance_tier                 = "P30"          # Higher than default tier for build performance
  
  managed_image_name                = "my-output-image"
  managed_image_resource_group_name = "my-rg"
  # ... other configuration
}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[sgreene570]

tweaked and tested, working on my end!

Going to merge to our fork so we can important into our other repos seamlessly - can always follow up with additional PRs as neede.