hashicorp / hashicorp/packer-plugin-azure

Packer azure-arm plugin does not expose knob for setting OS disk performance tier

Open
#548 2 comments 5 reactions 0 assignees View on GitHub
enhancement
Dominant language
Go
Stars
63
Forks
103
PR merge metrics
No merged PRs in 30d

Description

#### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

#### Description

When creating a VM, Azure assigns the VM's OS disk a default [performance tier](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-change-performance#what-tiers-can-be-changed) based on the configured size of the disk in GiB (rounded down to the closest power of 2).

For particularly small disks (e.g. 32 gb) the default performance tier can provide minimal throughput / IOPS, which can result in very long-winded packer build operations (e.g. rsync'ing lots of files around).

Ideally packer would expose a simple field, e.g. `os_disk_performance_tier`, alongside the current `os_disk_size_gb` [field](https://developer.hashicorp.com/packer/integrations/hashicorp/azure/latest/components/builder/arm#:~:text=os_disk_size_gb%20(int32)%20%2D%20Specify%20the%20size%20of%20the%20OS%20disk%20in%20GB%20(gigabytes).%20Values%20of%20zero%20or%20less%20than%20zero%20are%20ignored.), to support manually bumping the performance specs of the deployed OS disk without having to increase the final image artifact size.

As a workaround we have been bumping the OS disk's performance tier via the [azure CLI](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-performance-tiers?tabs=azure-cli) as an additional shell provisioner step once the VM is created, however, this is a control plane operation and as such can take anywhere from 5 minutes to 1 hour to complete based on regional disk system load. Azure support has confirmed that creating the VM with the desired performance tier will result in the provisioned IOPS being available immediately as an alternative.

#### Use Case(s)

Creating small packer images on top of Azure premium SSDs that require lots of file operations during the build process.

#### Potential configuration

Add new field for `azure-arm` plugin:
```
os_disk_performance_tier: P30
```

[Performance tier specs](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-size).

#### Potential References

- https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-size
- https://developer.hashicorp.com/packer/integrations/hashicorp/azure/latest/components/builder/arm
- https://learn.microsoft.com/en-us/azure/virtual-machines/disks-change-performance
- https://learn.microsoft.com/en-us/azure/virtual-machines/disks-performance-tiers?tabs=azure-cli

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.