Questions about: Switch to build managed image instead of VHD (#8167) (#8208)

[feliasson]

I am really confused about the drastic changes in #8167 and #8208, as both helpers GenerateResourcesAndImage.ps1 and CreateAzureVMFromPackerTemplate.ps1 contains breaking changes for anyone else currently using those for integrations based on previous version of create-image-and-azure-resources.md.

If the intention is to ensure the VM's are not using unmanaged disks going forward, it becomes weird we are suddenly forced to generate managed image, while it could simply be added that a managed disk would be created based on the storage account page blob VHD artifact, and optionally delete this source page blob thereafter.

Simply adding i.e.
az disk create --name $ManagedDiskName --resource-group $ResourceGroupName --source <URI-to-generated-page-blob-VHD-in-storage-account>
After a successful packer build would give you a finished managed disk artifact after GenerateResourcesAndImage.ps1 to be used by the VM to be created in CreateAzureVMFromPackerTemplate.ps1, and it could simply be added without introducing any breaking changes.

param (
       <-->
        [Parameter(Mandatory)]
        [string]$ManagedDiskId,
        [Parameter(Mandatory)][ValidateSet("Linux","Windows")]
        [string]$OsType
)

    Write-Host "`nCreating the VM"
    az vm create `
        --resource-group $ResourceGroupName `
        --name $VirtualMachineName `
        --attach-os-disk $ManagedDiskId `
	--os-type $osType `
        --size $vmSize `
        --admin-username $AdminUsername `
        --admin-password $AdminPassword `
        --nics $networkId `
        --subscription $subscriptionId `
        --location $AzureLocation

Another thing that is confusing for me is seeing that you have added steps in your own CI here in the same PR's that seem to be doing the following:

• Finalizes a Managed Image Version ->
• Creates a Managed Disk based on this image version ->
• Generates SAS URL for the Managed Disk ->
• Copies this Managed Disk to a Storage Account to become a page blob VHD ->
• Optionally removes the Managed Image ->
• Revokes access to Managed Disk ->
• Deletes Managed Disk ->
• Deletes Managed Image Version

...and what you have left is a page blob VHD copied to a storage account while everything else added to the other helpers was to not get a page VHD blob? Really confusing.

Could someone give some input why all these drastic changes were needed to be done to the helpers simply to not default to using unmanaged disks ? It seems it could have been made a lot easier and without any breaking changes to the helpers at least.

[mikhailkoliada]

Hey!

We still preserve a vhd file, but since September 30th it will be prohibited to create a new unmanaged disk on newly created subscriptions in azure, we have to make sure that the ones who would love to get vhd can still do it, i.e. we do not yet migrate to compute galleries / unmanned disks for the time being, just preserve the old approach different way

[fajterini]

Hi Mikhail,

Did I understand correctly if we are using your modified CI pipeline for internal build, but the new convert to VHD step/task is not needed if already use compute galleries (added logic in our pipeline) ? Currently Build VM task is already generating image version. I just started to fix/rework our solution :)

Thanks also to Frederik to start this Discussion :)

[mikhailkoliada]

@fajterini correct, if your final intention is to use a managed disk / compute gallery you may stop here, for us it is an interim step of getting a VHD blob ready, as most of the customers still prefer vhd, might be we could even implement a choice logic like "Do you want to generate VHD? [Y/n]"

[feliasson]

Do you mean the old way would stop working September 30th 2023 because the temporary VM during packer build is using unmanaged disk and that would be prevented?

If so, that makes it more clear for me at least to as why the drastic changes are performed to the helper scripts which also removed support for "the old way".

I also missed the small sentence about September 30th 2023 (ref here) that would prevent it from being created, I just saw the big headline about deprecation in September 30th 2025.

Thanks in advance!

[mikhailkoliada]

@feliasson as far as I understand, after September 30th, any new subscriptions will be banned from creating a VHD blob, the old ones will still be supported, at least for the time being, Surely, we can't predict if a customer is going to use a new one or the old one subscription, so we went ahead with the uniform approach for everyone.

[rybal06]

Has anyone been able to successfully get the packer output managed image (without the conversion steps in https://github.com/actions/runner-images/blob/main/images.CI/linux-and-win/convert-to-vhd.ps1) working for Windows Server 2022?

Linking the Ubuntu packer managed images directly to a VM/VMSS works perfectly, but the Windows 2022 get stuck in a "Creating" state. I can see the screen capture of the windows login screen so it is deploying, but it seems like it is not specializing correctly and getting stuck.

As a test, I removed all provisioners from the Windows2022.json file except for generalization, and it works perfect then.

        {
            "type": "powershell",
            "inline": [
                "if( Test-Path $Env:SystemRoot\\System32\\Sysprep\\unattend.xml ){ rm $Env:SystemRoot\\System32\\Sysprep\\unattend.xml -Force}",
                "& $env:SystemRoot\\System32\\Sysprep\\Sysprep.exe /oobe /generalize /mode:vm /quiet /quit",
                "while($true) { $imageState = Get-ItemProperty HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Setup\\State | Select ImageState; if($imageState.ImageState -ne 'IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE') { Write-Output $imageState.ImageState; Start-Sleep -s 10  } else { break } }"
            ]
        }

When I add back all of the provisioners which are in the repo it gets stuck in that "creating" state again.

I am currently going through the conversion steps in https://github.com/actions/runner-images/blob/main/images.CI/linux-and-win/convert-to-vhd.ps1; to see if I can still repro this issue. I'd rather use the managed image directly because unmanaged disks are quickly being deprecated, the extra conversion steps are very slow, and extra steps makes this process more fragile.

Is what I am seeing when trying to use the windows 2022 image directly as produced by Packer with all provisioners present excepted behavior?

[vpolikarpov-akvelon]

Hey @rybal06. I succeeded creating Windows 2022 VM using both managed image and VHD. I suppose there is something different in your environment that causes phenomenon you have described.

[rybal06]

Thanks for the reply - I just figured out that the issue I was facing was that autoprovisioning of azure defender for VMs was enabled which was interfering with sysprep generalization during image provisioning. I added a step to our pipeline which checks for that setting on the subscription now so that we can get a good error message in the future.

On a side note - I am really grateful for the MS team maintaining this repo which allows us to have agents which work exactly as MS-hosted; but can be placed on our private networks. With this latest change I was able to simplify my workflows a lot by getting rid of VHDs.

I don't fully understand why Microsoft is changing the images back to unmanaged VHDs; as this is slow and somewhat complicated and they have been long deprecated. My hunch is maybe Microsoft has some specific / internal capability to have 256GB temp disks for use with ephemeral agents which requires using unmanaged disks? There are no customer-facing SKUs which match the CPU/Memory of the Microsoft hosted agents and also support a 256GB temp disk.

[vpolikarpov-akvelon]

We converting managed images back to VHDs due to some special aspects of runners infrastructure. I don't think anyone else needs it since VHDs are deprecated.

[samus-aran]

We're locking this discussion because it has not had recent activity and/or other members have asked for more information to assist you but received no response. Thank you for helping us maintain a productive and tidy community for all our members.