1
00:00:00,740 --> 00:00:04,420
How do we resize an Azure VM programmatically with PowerShell?

2
00:00:04,420 --> 00:00:07,990
Well, we're going to be using Azure PowerShell, and in this code

3
00:00:07,990 --> 00:00:10,080
example we're setting up some variables,

4
00:00:10,080 --> 00:00:11,900
one for our Azure resource group,

5
00:00:11,900 --> 00:00:16,400
another for the virtual machine name. Just to see what VM sizes are

6
00:00:16,400 --> 00:00:21,920
available, we can run Get‑AzVMSize. We can get a reference to a VM in

7
00:00:21,920 --> 00:00:26,490
particular with Get‑AzVM. To do the resize operation, we're using

8
00:00:26,490 --> 00:00:31,550
PowerShell dot notation to access the VM size property, as you can see

9
00:00:31,550 --> 00:00:37,520
here, vm.HardwareProfile.VmSize, and you just specify the new size that you

10
00:00:37,520 --> 00:00:39,670
want. And then to cement that change,

11
00:00:39,670 --> 00:00:43,540
you'll do Update‑AzVM, and that VM will need to be restarted

12
00:00:43,540 --> 00:00:45,920
to pick up the new virtual machine size.

13
00:00:45,920 --> 00:00:48,490
So this is how to do it programmatically. In the demo,

14
00:00:48,490 --> 00:00:51,140
I'll resize using the Azure portal.

15
00:00:51,140 --> 00:00:55,680
This lesson is really about Azure VM subsystems. We just finished size,

16
00:00:55,680 --> 00:00:57,930
which is really the compute subsystem.

17
00:00:57,930 --> 00:00:58,360
Next,

18
00:00:58,360 --> 00:01:01,210
we'll turn our attention here to the storage subsystem, and

19
00:01:01,210 --> 00:01:03,870
we'll finish this module by looking at network.

20
00:01:03,870 --> 00:01:06,420
So what do we see here from left to right? Well,

21
00:01:06,420 --> 00:01:10,130
you see a virtual machine, obviously, and that VM in Azure has

22
00:01:10,130 --> 00:01:12,490
one, and only one, operating system disk.

23
00:01:12,490 --> 00:01:16,850
Of course, this all applies to Linux, as well as it does to Windows, but for

24
00:01:16,850 --> 00:01:21,940
like the 500th time I'll say that AZ‑800 and AZ‑801 are about the Windows

25
00:01:21,940 --> 00:01:26,780
Server Hybrid Administrator, so our OS disk is going to be surfaced in the

26
00:01:26,780 --> 00:01:29,690
VM operating system as your C drive.

27
00:01:29,690 --> 00:01:32,370
Now, if we look at the right‑hand side of the page,

28
00:01:32,370 --> 00:01:35,270
what is our D drive is our temp disk. On Linux

29
00:01:35,270 --> 00:01:37,850
machines, the mount point is /dev/sdb.

30
00:01:37,850 --> 00:01:42,110
And the good about the temp disk is that it's almost always solid state, so

31
00:01:42,110 --> 00:01:44,750
you're going to get really nice read/write performance.

32
00:01:44,750 --> 00:01:48,950
The bad news is you never ever want to put persistent data on your D

33
00:01:48,950 --> 00:01:53,100
drive on your Azure VM because there's many different things that either

34
00:01:53,100 --> 00:01:57,000
you could initiate or Microsoft could initiate that would involve your

35
00:01:57,000 --> 00:02:01,990
VM being live migrated to another hardware host in your server rack in

36
00:02:01,990 --> 00:02:03,210
the Azure data center.

37
00:02:03,210 --> 00:02:04,530
Why is that a big deal?

38
00:02:04,530 --> 00:02:08,920
Well, because the temp storage is associated with each hardware host.

39
00:02:08,920 --> 00:02:14,250
So the temp disk is great for truly ephemeral operations, but never

40
00:02:14,250 --> 00:02:18,030
to store persistent data on it, okay? And then lastly, we have the

41
00:02:18,030 --> 00:02:22,100
option of attaching N number of data disks to our VM. And again, we

42
00:02:22,100 --> 00:02:23,450
get great flexibility.

43
00:02:23,450 --> 00:02:27,120
You can resize these disks. If you start with the lower speed

44
00:02:27,120 --> 00:02:30,720
standard storage that's mechanical and you decide you have a need for

45
00:02:30,720 --> 00:02:35,290
more predictable IOPS, you can easily and trivially change the disk

46
00:02:35,290 --> 00:02:37,550
type to solid state and vice versa.

47
00:02:37,550 --> 00:02:41,670
We have so much agility and flexibility with the storage subsystem.

48
00:02:41,670 --> 00:02:44,990
But note that the maximum number of data disks that are allowed on

49
00:02:44,990 --> 00:02:47,940
your VM is dependent on the VM size.

50
00:02:47,940 --> 00:02:50,190
Here's an exam alert for AZ‑800.

51
00:02:50,190 --> 00:02:53,710
You absolutely need to know how to add a data disk to an Azure VM.

52
00:02:53,710 --> 00:02:57,600
First, we need to make sure that you're using a VM role size that

53
00:02:57,600 --> 00:03:02,080
supports a data disk, or if you already have data disks attached to

54
00:03:02,080 --> 00:03:03,640
the VM and you've reached your limit,

55
00:03:03,640 --> 00:03:07,090
you may need to resize the VM to have extra slots open

56
00:03:07,090 --> 00:03:09,250
up. Next, regardless of how you do it,

57
00:03:09,250 --> 00:03:12,220
whether it's in the Azure portal or Azure CLI or

58
00:03:12,220 --> 00:03:15,030
PowerShell, you need to add the disk to your VM.

59
00:03:15,030 --> 00:03:18,250
Now that could be a new empty Azure data disk or it could

60
00:03:18,250 --> 00:03:21,580
be an existing data disk that you have in the managed

61
00:03:21,580 --> 00:03:23,470
disks area of your subscription.

62
00:03:23,470 --> 00:03:24,420
Doesn't really matter.

63
00:03:24,420 --> 00:03:27,870
But you add the disk to your VM, and then here's the important point. In

64
00:03:27,870 --> 00:03:31,960
order to surface that data disk in your guest OS, you're going to need

65
00:03:31,960 --> 00:03:35,070
to log in to your guest OS and initialize,

66
00:03:35,070 --> 00:03:37,550
create volumes, and so on and so forth.

67
00:03:37,550 --> 00:03:40,940
And you could use Disk Management, MMC Console, or whatever.

68
00:03:40,940 --> 00:03:42,550
But that step is critical.

69
00:03:42,550 --> 00:03:46,320
So that middle step of adding the disk to your VM is directly

70
00:03:46,320 --> 00:03:49,610
analogous to you physically installing a data disk in the

71
00:03:49,610 --> 00:03:51,540
chassis of a physical computer.

72
00:03:51,540 --> 00:03:54,450
And just how you do with a physical computer, you then need

73
00:03:54,450 --> 00:04:01,000
to initialize, partition, format from the perspective of the guest OS. Same thing in Azure