Packer: Azure Builder: Packer should not delete OS Disk

[vladfr]

Currently, Azure does not have a way to copy Managed Images across regions / subscriptions. The only workaround is to copy the OS Disk and build an image in the new subscription.

If you use the VHD builder, this is not an issue. But with the Image builder, packer deletes the disks. The Managed Image does not have a Source Disk, and therefore cannot be copied.

There's a CLI command to automate Image copying, but it too relies on the Image having Disks: https://github.com/Azure/azure-cli-extensions/tree/master/src/image-copy

I also noticed Packer wants to deprecate the VHD builder:
"Warning: You are using Azure Packer Builder to create VHDs which is being deprecated, consider using Managed Images"

Is there a way to keep the disks used to build the image? If that can happen, then I believe the az image copy command would work.

[vladfr]

As a workaround, I've done the copying in the last provisioner. This works fine, but it requires the additional step of creating the final image outside of packer.

[lyda]

Yes please, this is also something I'd need. I was coming here to lodge the exact same bug, using the exact same utility, so thanks for the well written issue description!

@vladfr Any chance you could post the last provisioner step?

[danieldop]

Joining in for this feature request.
More information about the aforementioned cli extension can be found here.

[vladfr]

@lyda I would but it's rather ugly :) It's a bash with shell-local, just make sure it's the very last one, after the deprovision command that Azure requires.

I basically use az cli to do az vm show and fetch all the disks using jq. Tip: you'll need to hard-code the resource group name in packer.json, I couldn't find a way to get it as a var in the scripts.

[riezebosch]

Shared Image Gallery is the way forward I suppose and that's already supported. Didn't have a chance to try it out though. The same thing applies to copying the managed image to another region which is not possible yet. But therefor a zone resilient image would probably suffice (#6163).

[boumenot]

This is what I would recommend. There's also a PR that's currently under review to snapshot the disk(s) before it is deleted.

[phillipsj]

I was about to file this same bug. The reason for filling is slightly different. We are using Packer to create images for the Azure Marketplace which only accepts VHDs. When we create an Image we can't get to the VHD to use it to submit because has been deleted.

[riezebosch]

One option would be to specify the capture_container_name, capture_name_prefix, resource_group_name and storage_account. That way you end up with a VHD in a storage account. Source: https://www.packer.io/docs/builders/azure.html#vhd-or-managed-image

[phillipsj]

Yes, we do that currently. If that is being deprecated then what is the
long term solution.

On Fri, Nov 30, 2018, 11:24 AM Manuel Riezebosch [e-mail]
wrote:

One option would be to specify the capture_container_name,
capture_name_prefix, resource_group_name and storage_account. That way
you end up with a VHD in a storage account. Source:
https://www.packer.io/docs/builders/azure.html#vhd-or-managed-image

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/packer/issues/6752#issuecomment-443257397,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABfthYaJL5ONTtHUCXqOePJ-zd9KBvmVks5u0VukgaJpZM4W0JDe
.

[boumenot]

Our current thinking is to create a snapshot of the disk(s). The PR has been merged, and should be available in the next Packer release.

The docs have not been published yet because this is an unreleased feature, but in the interim see https://github.com/hashicorp/packer/blob/master/website/source/docs/builders/azure.html.md.

• managed_image_os_disk_snapshot_name (string) If managed_image_os_disk_snapshot_name
  is set, a snapshot of the OS disk is created with the same name as this value before the
  VM is captured.

• managed_image_data_disk_snapshot_prefix (string) If managed_image_data_disk_snapshot_prefix
  is set, snapshot of the data disk(s) is created with the same prefix as this value before the VM
  is captured.

[jonesbusy]

Hi!

Is anyone was able to copy a managed image to an other region after packer build on Azure ? (using az image copy) ?

We are using 'managed_image_os_disk_snapshot_name' in order to keep the snapshot, but even with that it's not possible to move the managed image to an other region.

It seems that the CLI needs the OS disk to be not deleted. Is there a way to keep the OS disk ? (Or to not delete at all temporary resources ?

az image copy --source-object-name <sourcename> --source-resource-group <sourcegroup> --target-name <image target> --target-resource-group <target rg> --source-type image --target-location westeurope --target-subscription <target subscription>

WARNING: Getting os disk id of the source vm/image
WARNING: Creating source snapshot
ERROR: command failed: ['/usr/local/bin/python', '-m', 'azure.cli', 'snapshot', 'create', '--name', '**********', '--resource-group', '****', '--source', '/subscriptions/****/resourceGroups/*****/providers/Microsoft.Compute/disks/pkrosa9okt15pzk', '--output', 'json', '--tags', 'created_by=image-copy-extension']
ERROR: output: ERROR: Resource pkrosa9okt15pzk is not found.

ERROR: The command failed with an unexpected error. Here is the traceback:

ERROR: Command '['/usr/local/bin/python', '-m', 'azure.cli', 'snapshot', 'create', '--name', '******', '--resource-group', '*****', '--source', '/subscriptions/****/resourceGroups/**********/providers/Microsoft.Compute/disks/pkrosa9okt15pzk', '--output', 'json', '--tags', 'created_by=image-copy-extension']' returned non-zero exit status 1.
Traceback (most recent call last):

Help would be very appreciated :)

Thanks in advance.

[riezebosch]

Use "managed_image_zone_resilient": true so you don't have to copy.

[Boriszn]

Hey guys,

Any updates on this topic. We really need this fix to move forward.

Could you please help us.
Thanks a lot in advance.