Support disk snapshot as source for Azure compute gallery image destination #528
Description
Description
Temp Packer VMs today are created as "Standard" or Non-Trusted launch VMs by default which are then used to successfully create image versions in image definitions with following security types:
- TrustedLauchSupported (TLSupported)
- ConfidentialVMSupported (CVMSupported)
- TrustedLaunchAndConfidentialVMSupported (TLAndCVMSupported)
Image versions cannot be generated successfully if the temp packer VM is a Trusted launch VM.
Note: Azure compute gallery images with security type TrustedLaunch or ConfidentialVM is not in scope of this thread.
Why existing flow does not work with Trusted launch Packer VM
Packer uses Managed image as default temp resource for generating the target Azure compute gallery image version (as shown below)
packer {
required_plugins {
azure = {
version = ">= 2.0.0"
source = "github.com/hashicorp/azure"
}
}
}
variable "subscription_id" {
type = string
default = ""
}
variable "resource_group_name" {
type = string
default = "packer-rg"
}
variable "gallery_name" {
type = string
default = "packerAcg"
}
variable "image_name" {
type = string
default = "PackerImageDef"
}
variable "image_version" {
type = string
default = "1.0.0"
}
variable "location" {
type = string
default = "westus3"
}
source "azure-arm" "ws2022" {
// Force authentication using Azure CLI
use_azure_cli_auth = true
// Authentication via Azure CLI is used by default
subscription_id = var.subscription_id
// Location for temporary build resources
location = var.location
// Tags for temporary build resources
azure_tags = {
"created_by" = "packer"
"purpose" = "image-build"
}
// Base Image Details
managed_image_resource_group_name = var.resource_group_name
managed_image_name = "packer-temp-image-${uuidv4()}"
// VM Details for the build
vm_size = "Standard_D2s_v3"
os_type = "Windows"
image_publisher = "MicrosoftWindowsServer"
image_offer = "WindowsServer"
image_sku = "2022-datacenter-azure-edition"
image_version = "latest"
// Explicitly define the communicator for Windows
communicator = "winrm"
winrm_use_ssl = true
winrm_insecure = true
winrm_timeout = "5m"
winrm_port = 5986
// Destination: Azure Compute Gallery
shared_image_gallery_destination {
resource_group = var.resource_group_name
gallery_name = var.gallery_name
image_name = var.image_name
image_version = var.image_version
replication_regions = [var.location]
}
}
build {
sources = ["source.azure-arm.ws2022"]
provisioner "powershell" {
inline = [
"Write-Host 'Installing IIS Web Server...'",
"Install-WindowsFeature -name Web-Server -IncludeManagementTools",
"Write-Host 'Customization complete.'"
]
}
// This post-processor is not strictly required but is good practice
// to ensure the temporary managed image created during the build is deleted.
post-processor "manifest" {}
}
Since Managed images are not supported with Trusted launch and Confidential VMs, this default flow does not supports using Trusted launch or Confidential VM as temp Packer VM.
ASK
Request to support generating Azure compute gallery image versions using managed_image_os_disk_snapshot_name instead of managed_image_name.
This will remove the dependency on Managed image and allow generating Azure compute gallery image versions for all image definitions with security types listed above and for image definitions without any security type configured.
Revised proposed flow is:
Following JSON has been validated with revised flow and custom orchestration to extract VHD from the snapshot.
{
"builders": [
{
"azure_tags": {
"imageTemplateName": "PackerArmWs2022acgpf",
"imageTemplateResourceGroupName": "packer-rg"
},
"build_resource_group_name": "",
"cloud_environment_name": "Public",
"communicator": "winrm",
"disk_caching_type": "None",
"image_offer": "WindowsServer",
"image_publisher": "MicrosoftWindowsServer",
"image_sku": "2022-datacenter-azure-edition",
"image_version": "20348.3807.250605",
"managed_image_name": "packerImg_20250703183246",
"managed_image_os_disk_snapshot_name": "packerImg_20250703183246_os_disk",
"managed_image_resource_group_name": "",
"metadata_host": "management.azure.com",
"os_disk_size_gb": 127,
"os_type": "Windows",
"polling_duration_timeout": "30m",
"skip_create_image": true,
"subscription_id": "",
"type": "azure-arm",
"virtual_network_name": "packervnet4fmx6",
"virtual_network_resource_group_name": "",
"virtual_network_subnet_name": "remotesubnet",
"vm_size": "Standard_D2s_v3",
"winrm_insecure": true,
"winrm_timeout": "30m",
"winrm_use_ssl": true,
"winrm_username": "packer"
}
],
"provisioners": []
}
Use Case(s)
Managed image is a legacy resource with recommendation to move away from. Above requested ask will help removing dependency on managed images.
Trusted launch is planned to be default security type for VMs. Removing dependency from managed image and moving to snapshots instead will provide seamless transition to Azure users from Standard to Trusted launch VMs.
Note: In near future, Azure VM API will expose Standard as supported security type which can be used to bypass Trusted launch default. However, bypassing Trusted launch for temp packer VMs as solution is not recommended because:
- It will not remove or address the dependency on Managed image.
- Trusted launch security type will ensure boot integrity of temp packer VMs. i.e., no malware, bootkit or rootkit will get introduced into the customer's Azure compute gallery images which is used to deploy multiple VMs.
Other configurations attempted
I tried following configuration which generated following error.
packer {
required_plugins {
azure = {
version = ">= 2.0.0"
source = "github.com/hashicorp/azure"
}
}
}
variable "subscription_id" {
type = string
default = ""
}
variable "resource_group_name" {
type = string
default = "packer-rg"
}
variable "gallery_name" {
type = string
default = "packerAcg"
}
variable "image_name" {
type = string
default = "packerImageDef"
}
variable "image_version" {
type = string
default = "1.0.0"
}
variable "location" {
type = string
default = "westus3"
}
source "azure-arm" "ws2022" {
// Force authentication using Azure CLI
use_azure_cli_auth = true
// Authentication via Azure CLI is used by default
subscription_id = var.subscription_id
// Location for temporary build resources
location = var.location
// Tags for temporary build resources
azure_tags = {
"created_by" = "packer"
"purpose" = "image-build"
}
// Base Image Details
storage_account = "packer1808sa"
capture_container_name = "images"
capture_name_prefix = "packer"
resource_group_name = var.resource_group_name
// VM Details for the build
vm_size = "Standard_D2s_v3"
os_type = "Windows"
image_publisher = "MicrosoftWindowsServer"
image_offer = "WindowsServer"
image_sku = "2022-datacenter-azure-edition"
image_version = "latest"
// Explicitly define the communicator for Windows
communicator = "winrm"
winrm_use_ssl = true
winrm_insecure = true
winrm_timeout = "5m"
winrm_port = 5986
// Destination: Azure Compute Gallery
shared_image_gallery_destination {
resource_group = var.resource_group_name
gallery_name = var.gallery_name
image_name = var.image_name
image_version = var.image_version
replication_regions = [var.location]
}
}
build {
sources = ["source.azure-arm.ws2022"]
provisioner "powershell" {
inline = [
"Write-Host 'Installing IIS Web Server...'",
"Install-WindowsFeature -name Web-Server -IncludeManagementTools",
"Write-Host 'Customization complete.'"
]
}
// This post-processor is not strictly required but is good practice
// to ensure the temporary managed image created during the build is deleted.
post-processor "manifest" {}
}
Error
Error: 1 error(s) occurred:
* Specify either a VHD (storage_account and resource_group_name), a Managed Image (managed_image_resource_group_name and managed_image_name) or a Shared Image Gallery (shared_image_gallery_destination) output (Managed Images can also be published to Shared Image Galleries)
on .\packer-vhd-template.pkr.hcl line 40:
(source code not available)
Community Note
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, 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.