slide

Adding linux images to azure stack

Ned Bellavance
4 min read

Cover

If you are planning to add Linux Images to your Azure Stack deployment, first I would recommend reading through the documentation on the Azure Stack pages for Adding a VM Image and Using Custom Linux Images.  From there you can get the base images and the process for adding the images to Azure Stack.  What they don’t include is the Azure Cloud information for the various images, and if you would like to be able to use a JSON template against both Azure and Azure Stack without changing the image information, then you will want the publisher, offer, sku, and version to match.  In this post I will walk through the basics of adding one Linux image, how to get the necessary information from Azure Cloud, and the current information for the images you may want to run.

All of these commands will be run from the Mas-Con01 VM in Azure Stack.  You can run it from your local workstation if you set up a P2S VPN tunnel, but that’s a topic for another post.  I am also running this on Azure Stack TP3, so if you are on a previous version your results may vary.  Finally, I bump the Mas-Con01 VM up to 8GB of memory and turn off Windows Defender.  That’s a personal choice; however, I think you’ll find that it speeds up anything you are planning to run on Mas-Con01 tremendously.

Step 1 - Install the Azure Stack tools and Azure Stack PowerShell

From an Administrative PowerShell session run the following:

Step 2 - Retrive the VM Image information for Azure Cloud

For this example I will be finding the VM Image information for Ubuntu Server 16.04 LTS.  The first step is to log into Azure via PowerShell using Login-AzureRMAccount.  Then the following commands will retrieve the information you would want.

Once the commands are finished running, you should get output that looks roughly like this:

Step 3 - Download and Add Image

Now you have all the necessary values to add the Ubuntu image to your local Azure Stack installation.  The next thing to do is download the images from the Deploy Linux virtual machines on Azure Stack page I linked before.  Keeping with the theme of Ubuntu, I am downloading the 16.04 LTS image linked on the page.  Right now that link is broken, so you can use this one instead if Microsoft hasn’t fixed it yet.  The file will be compressed, and so you’ll need to extract it.  The VHD is ~30GB in size, so I recommend copying it to the infrastructure file share created during the Azure Stack install, which should be \\SU1fileserver\SU1_Infrastructure_1.  That way you won’t run out of room on Mas-Con01 as you download and add more images.

Once the VHD file has been extracted, make a note of the location and run the following to add the VM Image.

You’ll be prompted for your Azure Stack credentials, and you’ll need to change the tenant to match whatever you used when installing Azure Stack.  In the end you will now have a new VM Image in the marketplace.

Here is a table with all the current images linked on the Microsoft page:

PublisherName

Offer

Sku

Version

Title

Location

OpenLogic

CentOS

6.8

6.8.20170105

CentOS-based 6.8

Local

OpenLogic

CentOS

7.2

7.2.20170105

CentOS-based 7.2

Local

CoreOS

CoreOS

Stable

1298.6.0

CoreOS Linux (Stable)

Local

SuSE

SLES

12-SP1

    1. 10.21

SLES 12 SP1

Local

Canonical

UbuntuServer

16.04-LTS

16.04.201703270

Ubuntu Server 16.04 LTS

Local

Canonical

UbuntuServer

14.04.5-LTS

14.04.201703230

Ubuntu Server 14.04 LTS

Local

Note that the version numbers are subject to change, so you may want to verify what version you have downloaded.  Regardless, the latest version is automatically selected if you specify “latest” in your ARM template.

A word about the Sku property.  The current version of the Add-VMImage cmdlet in the AzureStack.ComputeAdmin module does not allow for a “.” in the Sku parameter.  You can either avoid using a “.” or alter the validation criteria for the parameter by changing the expression from “[a-zA-Z0-9-]{3,}” to “[a-zA-Z0-9-\.]{3,}” in the Add-VMImage function.  Doing so does not seem to affect the deployment of new images.