How do we resize an Azure VM programmatically with PowerShell?
Well, we're going to be using Azure PowerShell, and in this code
example we're setting up some variables,
one for our Azure resource group,
another for the virtual machine name. Just to see what VM sizes are
available, we can run Get‑AzVMSize. We can get a reference to a VM in
particular with Get‑AzVM. To do the resize operation, we're using
PowerShell dot notation to access the VM size property, as you can see
here, vm.HardwareProfile.VmSize, and you just specify the new size that you
want. And then to cement that change,
you'll do Update‑AzVM, and that VM will need to be restarted
to pick up the new virtual machine size.
So this is how to do it programmatically. In the demo,
I'll resize using the Azure portal.
This lesson is really about Azure VM subsystems. We just finished size,
which is really the compute subsystem.
Next,
we'll turn our attention here to the storage subsystem, and
we'll finish this module by looking at network.
So what do we see here from left to right? Well,
you see a virtual machine, obviously, and that VM in Azure has
one, and only one, operating system disk.
Of course, this all applies to Linux, as well as it does to Windows, but for
like the 500th time I'll say that AZ‑800 and AZ‑801 are about the Windows
Server Hybrid Administrator, so our OS disk is going to be surfaced in the
VM operating system as your C drive.
Now, if we look at the right‑hand side of the page,
what is our D drive is our temp disk. On Linux
machines, the mount point is /dev/sdb.
And the good about the temp disk is that it's almost always solid state, so
you're going to get really nice read/write performance.
The bad news is you never ever want to put persistent data on your D
drive on your Azure VM because there's many different things that either
you could initiate or Microsoft could initiate that would involve your
VM being live migrated to another hardware host in your server rack in
the Azure data center.
Why is that a big deal?
Well, because the temp storage is associated with each hardware host.
So the temp disk is great for truly ephemeral operations, but never
to store persistent data on it, okay? And then lastly, we have the
option of attaching N number of data disks to our VM. And again, we
get great flexibility.
You can resize these disks. If you start with the lower speed
standard storage that's mechanical and you decide you have a need for
more predictable IOPS, you can easily and trivially change the disk
type to solid state and vice versa.
We have so much agility and flexibility with the storage subsystem.
But note that the maximum number of data disks that are allowed on
your VM is dependent on the VM size.
Here's an exam alert for AZ‑800.
You absolutely need to know how to add a data disk to an Azure VM.
First, we need to make sure that you're using a VM role size that
supports a data disk, or if you already have data disks attached to
the VM and you've reached your limit,
you may need to resize the VM to have extra slots open
up. Next, regardless of how you do it,
whether it's in the Azure portal or Azure CLI or
PowerShell, you need to add the disk to your VM.
Now that could be a new empty Azure data disk or it could
be an existing data disk that you have in the managed
disks area of your subscription.
Doesn't really matter.
But you add the disk to your VM, and then here's the important point. In
order to surface that data disk in your guest OS, you're going to need
to log in to your guest OS and initialize,
create volumes, and so on and so forth.
And you could use Disk Management, MMC Console, or whatever.
But that step is critical.
So that middle step of adding the disk to your VM is directly
analogous to you physically installing a data disk in the
chassis of a physical computer.
And just how you do with a physical computer, you then need
to initialize, partition, format from the perspective of the guest OS. Same thing in Azure