Playing around with Azure Stack HCI

Decided to have some fun with (nested) Microsoft Azure Stack HCI in my lab.

If you want to do the same, I’ve scripted most the stuff you need, so… maybe it will be useful.

Steps to prepare a brand new, shiny, nested Azure Stack HCI lab are (roughly):

  • prepare your (parent) Windows Server 2022 Hyper-V host (ensure enough resources are available)
    • it already hosts my Active Directory, DNS, DHCP, router, …,  VMs
    • everything will be saved locally to D:\AzureStackHCI
  • (optional) install Windows Admin Center (WAC) for easier management
    • download it and install with simple command:

  • obtain the Azure Stack HCI 60-day trial ISO image from here
  • make VHD(X) from the obtained ISO image:

    • note that I’m using Convert-WindowsImage.ps1 available here
    • which gives me nice, generalized Azure Stack HCI VHD(X), which we will “upgrade with things” and later use for VM creation
  • install prerequisites into VHD(X)
    • this one is fairly easy – install Windows roles and features directly to the VHD(X) itself:

    • NOTE: If you try to install the Hyper-V role later, it may fail as we’re running Azure Stack HCI on “normal” Windows Server, so it get’s confused with nested virtualization availability. With preinstaling it, we make sure it just works.
  • update VHD(X) with latest patches:

    • I have previously downloaded all the Azure Stack HCI patches available to D:\AzureStackHCI\Updates
  • add Unattend.xml to handle the “set password at first login issue”
    • it annoys me that I need to set up the initial password, so… simple Unattend.xml file, injected into VHD(X) should take care of this:

    • NOTE: Make sure you don’t use clear-text passwords in Unattend.xml file!
  • create Azure Stack HCI VMs
    • I’m creating two VMs from our prepared VHD(X), with a couple of additional data disks, few network adapters for different purposes, nested virtualization enabled, etc.:

  • set node networking, join them to the domain, prepare for cluster (by using PowerShell Direct):

  • create the Azure Stack HCI cluster:

  • register (optional) the Azure Stack HCI cluster:

  • create CSV(s) and virtual switches for child workloads (but add nodes/cluster to WAC before, if not using PowerShell)

  • play around with your new cluster
  • (optional) clean all/redeploy if needed:

And now you have fully functional, nested, 2-node Azure Stack HCI cluster – nothing too fancy, but you can extend it how you wish! 😊

You can begin exploring the Azure Stack HCI itself, use it with Azure Arc, or perhaps install AKS on Azure Stack HCI and play around with it. Or something else.

Cheers!

P.S. You can use these scripts also for stuff other than Azure Stack HCI, of course! 😉
P.P.S. Code is also available on my GitHub page.

Deploying Kubernetes on top of Azure Stack (Development Kit)

If you had a chance to deploy Azure Stack or Azure Stack Development Kit (ASDK) in your environment, maybe you’ve asked yourself “OK, but what should I do with it now?“.

Well, one of many things you “can do with it” is offer your users to deploy Kubernetes clusters on top of it (at least, that was what I did the other day… on my ASDK deployment) – in short, official documentation has you pretty much covered. I know, Azure enables it as well… and the process here is similar, or – the same.

The main thing you have to decide at the beginning, is if you’ll use Azure AD or ADFS for identity management (the same as with Azure Stack deployment, if you remember, from my previous posts). Why – because the installation steps differ a bit.

Once you decide it (or you ask your Azure Stack administrator how it’s done in your case), you can proceed with the installation – I assume you have your Azure Stack/ASDK up and running.

Next, in the admin portal (https://adminportal.local.azurestack.external/), you’ll need to add the prerequisites from Azure Marketplace (for this, if you remember, your Azure Stack/ASDK has to be registered):

Once done, you’re ready to set up the service principal, to which you’ll then assign the required permissions on both – the Azure side and on the Azure Stack side! (don’t forget this detail… it is well documented, but easy to overlook)

In case you don’t give your service principal the required permissions on both “sides”, you’ll probably get the “error 12” and your deployment will fail:

And you can see details in the log:

So… be careful with service principal and permissions! 🙂

Next thing you’ll need to make sure of is that you create a plan and an offer, but set your quotas right! It depends on your Kubernetes cluster deployment settings, but if you’ll go with the defaults, the default quotas (disk, in particular) need to be expanded!

If not, you’ll probably get this error:

If you were careful while reading the official docs (with a few “lessons learned” in this post), and you’ve made it to here… you’re probably set to deploy your first Kubernetes cluster on top of your Azure Stack/ASDK.

In the user portal (https://portal.local.azurestack.external/), you now have the option to deploy something called Kubernetes Cluster (preview):

Here you really can’t miss much – you’ll give your deployment a brand new (or empty) resource group, user details (together with your public SSH key, of course), DNS prefix, number and size of nodes and service principal details:

After that, your deployment starts and runs for some time (it, again, depends on your hardware and settings you’ve chosen for your cluster). Hopefully, it will end with this message:

If all is good, you can SSH into one of your master nodes and see the details of your cluster:

One other thing that would be nice to have is the Kubernetes dashboard – the process of enabling it is well documented here:

And – you’re done!

You now have your own Kubernetes cluster deployment on top of your Azure Stack/ASDK! How cool is that?! 🙂

One last thing to note – currently, this is in preview (as it says on the template), but… it works. 🙂

Cheers!

One step closer to Microsoft Azure Stack

Great news coming from Microsoft – we are so close to finally getting the Microsoft Azure Stack preview! But… not this calendar year, unfortunately.

Azure Stack will be a combination of Windows Server 2016, Azure Pack and Azure Service Fabric. Combined together, these components will deliver the new “private cloud” solution (or more precisely hybrid solution because you will be able to expand with “public cloud” resources, if needed), which looks and feels like the “big Azure”. Bottom line is that the experience using Azure Stack or Azure will be identical (i.e. Microsoft brings it’s Azure to our on-premises datacenter). Sounds cool! Smiješak

Microsoft released a “teaser” with hardware requirements for its Azure Stack, and who better to explain them than Jeffrey Snover himself. Enjoy this short video.

And the best thing of the whole video is that you’ll need only ONE standard server to host the Azure Stack. One to rule them all. Smiješak

Don’t forget to take a look at the official announcement here (and to purchase additional server if needed, so that you can play with Azure Stack Preview once it gets available).

Cheers!