AzS HCI HandsOn – Part 5 – VM Provisioning in Azure Stack HCI from Azure Portal using MSLabs

Being able to provision VMs through the public Azure portal has been an eagerly awaited feature amongst the AzS HCI community and finally it is here! And of course, I could not pass off the opportunity to try it myself ASAP! The official Msft documentation is here, and feel free to follow that, but honestly I hit errors while going by the documentation and soon I gave up. Unfortunately the documentation is not very clear, and I even spotted a couple errors in the scripts. So instead we’re going to fall back to the old trusty MSLabs guide by my good friend and colleague Jaromir Caspar here.

Replace the content of LabConfig with the code provided, and hit deploy. All this is going to do is deploy a DC server, and a couple of AzS HCI nodes. If you already have a lab with a cluster set up, you can skip this part and go straight to the scenario.

Log in to the DC server and open Powershell window as an administrator. We will paste the whole script in, but we’re going to run it in pieces so we can see what we’re doing.

So this is how this whole thing works:

We are going to need something called as an Azure Arc Resource Bridge which is basically a Kubernetes-based VM. As a part of this we will also need a MOC service running on one of the nodes. MOC is basically specific service that gets installed on the AzSHCI cluster nodes, and reflected in the cluster as a cluster object with an accompanying IP address, so that the K8s cluster in the AKS-HCI Management VM can communicate with the underlying AzSHCI cluster.

We also need a Custom Location, which is basically analogous to a region in the context of public Azure. And lastly, we will need a Cluster Extension which is analogous to the “Microsoft.Compute” ARM provide in public Azure.

Alright so lets get cracking. All I’m going to do is run through the MSLab scenario, and run the script region by region.

Alright, so that actually was VERY smooth. I floated through the entire script comfortably, without any error. And so this is what we now have in our hands!

Currently I have two clusters registered in Azure, ArcVMs-Cluster being the one where we enabled Arc-managed VM just now. Let’s see what has changed.

If you click into the cluster and go to Virtual Machines, you’ll see this:

Yayy! Looks like we were successful in our adventure just now, since it looks like we can now create VMs from here. Awesome!

Note that this feature is still in preview and you may have noticed that the VMs we created natively from WAC are not showing up here (as the note non the top indicates) yet. But hopefully, that’ll change in the coming improvements.

For reference, this is what appears in the same blade on the other cluster:

Cool, so now that we have the power of creating VMs in AzS HCI on prem from the public Azure portal, let’s go do exactly that!

Walking through the wizard was a breeze – give your VM a name, optionally add disks and network interfaces, add tags and hit create!

A few minutes later, the deployment is complete! Let’s navigate to the VM and see what we can do to it.

Right from the top menu I can see that you can Start, Restart, Stop and Delete this VM.

If you explore Settings, you’ll see that you can also do the following:

1. Add/remove additional disks
2. Add/remove network interfaces
3. Change the number of virtual processors and the amount of memory assigned           
4. The standard Azure features such as Activity Log, IAM, Tags, Locks and basic monitoring, etc.

Let’s jump quickly to the native WAC, and see if this new machine shows up in there.

And so it does! Cool. Let’s stop it here for now. See you in the next one!