Azure VM image does not have Source Blob URI - arm-template

After following the instructions for creating a managed image in Azure, I'm trying to create a VM from the managed image inside the ARM template. The ARM template requires a source blob URI which should be listed on the VM image page within the Azure portal, but it's blank (see screen shot below).
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/capture-image-resource
Did I miss a step somewhere?

yes, to create a vm from the managed disk image you need its resource id, not its uri (because it doesnt have one). Here's an ARM Template bit to create a VM from the managed disk image:
"storageProfile": {
"imageReference": {
"id": "[resourceId('Microsoft.Compute/images', concat(parameters('vmPrefix'), '-gateway-osImage'))]"
},
"osDisk": {
"name": "[concat(parameters('vmPrefix'), '-gateway-os-vhd')]",
"createOption": "FromImage"
}
},

Related

Create an azure VM from an image using availability zones and templates

I am currently deploying some new azure VMs using a template. This template contains a link to a VHD image and uses availability sets.
After having a look at the azure docs, I cannot seem to tell or find out if it's possible to use my current procedure to deploy the VM in a specific zone.
I changed my template to use zones rather than sets but when I use it in Azure CLI I have this error message returned:
"Virtual Machines deployed to an Availability Zone must use managed disks."
I then tried to add the managed disk section to the template without success.
Below there is the pseudocode of the template related to the storage of the VM:
"storageProfile": {
"osDisk": {
"managedDisk": {
"storageAccountType": "StandardSSD_LRS"
},
"osType": "Linux",
"name": "myName.vhd",
"createOption": "FromImage",
"image": {
"uri": "myUri.vhd"
},
"vhd": {
"uri": "myVhdImageUri.vhd"
},
"caching": "ReadWrite"
}
}
You have to convert disk to managed disk first. Then you will be able to use it in your template.

aks-engine custom image for node

On the aks-engine github there is an example for a custom image for a node as follows:
"agentPoolProfiles": [
{
"name": "agentpool1",
"count": 3,
"imageReference": {
"name": "stretch",
"resourceGroup": "debian"
},
"vmSize": "Standard_D2_v2",
"availabilityProfile": "AvailabilitySet"
}
]
When I use this in my aks-engine generated ARM it can't find the resource group because I have not created it and not uploaded an a debian VHD as an Image in Azure.
Is there a way of using pre-made images on Azure instead of having to upload our own?
If you mean to create a custom image without upload your own VHD file in Azure when you say using the pre-made images. Then the answer is yes. You can create the image from the base images that Azure provided in the marketplace through the Packer tool or Capture the image from the Azure VM.
As you see in the aks-engine custom image, you need to create the custom image in the resource group first, and then use both resource group name and image to quote the custom image to create the agent pool. The description in agentPoolProfiles of aks-engine.
If you are using Azure Kubernetes Service(AKS) to create a managed AKS cluster, you won't be able to use the custom image or the gke-engine.
See the comment from Microsoft's employee on Aug 3, 2018:
Currently, AKS does not support deploying custom VM image as agent
nodes. You can use ACS-Engine. Here is the link to open source version
of ACS-Engine: https://github.com/Azure/acs-engine

Mechanism to upload ARM template into storage

I want to use linked templates in my ARM deployment model. Every article I've read mentions that the linked template needs to be in an accessible location (such as blob storage).
This works OK if I manually upload the files to storage but I'm looking for a mechanism to upload a template to Storage as part of the build or Deployment process.
I'd hoped to use the Artifact Storage Account option but it is unavailable when deploying infrastructure only.
Is there a built-in method to achieve this or would it require either an extra step such as powershell script or VSTS build step?
The Artifact Storage Account option becomes available as soon as you introduce the two parameters _artifactsLocation and _artifactsLocationSasToken into your deployment.
"parameters": {
"_artifactsLocation": {
"type": "string",
"metadata": {
"description": "Auto-generated container in staging storage account to receive post-build staging folder upload"
}
},
"_artifactsLocationSasToken": {
"type": "securestring",
"metadata": {
"description": "Auto-generated token to access _artifactsLocation"
}
}
}

Azure Resource Manager: attach VHD to a VM during provisioning?

I'm trying to attach an existing VHD disk from a Storage Account to VM during Azure Resource manager provisioning with a template.
My dataDisk resource is:
"dataDisks": [
{
"name": "jmdisk",
"diskSizeGB": "100",
"lun": 0,
"vhd": {
"uri": "https://jmje.blob.core.windows.net/vhds/jenkinshome.vhd"
},
"createOption": "attach"
}
]
But during deploy - I have an error from Azure:
STATUSMESSAGE{
"error": {
"code": "OperationNotAllowed",
"target": "dataDisk",
"message": "Addition of a blob based disk to VM with managed disks is not supported."
}
}
Unfortunately can't google anything related, i.e. - a correct way to attach an existing disk.
UPD Solved this by just creating new Managed disk and copy data there.
You can create a managed disk from an existing blob -- you can see a sample of that here: https://github.com/chagarw/MDPP/blob/master/101-create-image-availabilityset-2vm-from-blob/azuredeploy.json
It uses existing blobs for both OS and data, you don't have to do it that way... In your case it sounds like you want an implicit OS disk and then an explicit data disk? Which you could also do, just use different images for each.
Well, the error gives it up, you are probably not familiar with Managed Disks yet. So you are creating a VM with OS disk as managed, in that case you cannot use existing disks to attach to a VM, just create a VM with regular disk (just like you do with data disk).

How can I deploy an Azure virtual machine scale set to an existing virtual network?

I have successfully deployed a VMSS with an AD server in the same VLAN. However, when I try to deploy a second VMSS it create a new virtual network, placing it away from my existing AD.
How do I deploy the second VMSS into the same virtual network as the first and AD? If I edit a template to have the same virtual network as the existing one, then deploy it, will the deployment be into the existing virtual network or will it attempt to create a new one with the same name and fail or duplicate it?
Alternatively, is there any way to migrate the NIC in a VMSS to another network? I can't find a cmdlet to do it and in the web interface it only shows the virtual network created at deployment in the drop-down and not the original virtual network.
If you deploy a template that has an identical vnet configuration a second time it will essentially no-op. If you change the config slightly on an existing work it will attempt to update that config.
Essentially what you want to do here is author the template such that it references the existing network via the NICs and not define the network itself. Your declaration is that the network "exists" so you do not need to define it only reference it. This is a snippet of the JSON:
"networkProfile": {
"networkInterfaceConfigurations": [
{
"name": "vmss-nic",
"properties": {
"primary": true,
"ipConfigurations": [
{
"name": "vmss-ipconfig",
"properties": {
"subnet": {
"id": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'), '/subnets/', variables('subnetName'))]"
}
The "id" property is the resourceId of the subnet for the vnet you want to place the VMSS in. If the vnet is in the same resource group as the VMSS you can shorten that expression to simply:
Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'), '/subnets/', variables('subnetName')
But the fully qualified id will work in all scenarios.
re: moving the VMSS, you can always try by deploying a template configured as above. Same VMSS name in the same RG but with a different network profile.
HTH

Resources