Here’s the rewritten version in a conversational, first-person style:

How I Manage Azure VMs: Resizing, Disks, Networking, and Moving Resources

If you spend any time managing Azure infrastructure, these four tasks will come up more often than you’d expect. I want to walk you through how I handle VM resizing, adding storage, fixing network issues, and moving resources — all in a way that actually makes sense in practice.

Resizing VMs Without Panicking

The first time someone asked me to “scale up” a VM, I overthought it. It’s actually straightforward — you’re just switching the VM’s SKU, which changes its CPU and memory. No redeployment, no data loss.

From the portal, go to your VM → Availability + scale → Size, pick your SKU, and hit Resize. Done.

But here’s the thing I wish someone had told me earlier: resizing always causes a restart. Plan for downtime. And sometimes Azure can’t resize without first deallocating the VM — this happens when your target size isn’t available on the current hardware cluster. The portal will tell you when that’s the case.oneuptime+1

I usually just do it from the CLI now. It’s faster and scriptable:

bash# Check what sizes are available for your VM first
az vm list-vm-resize-options \
  --resource-group AZ104-VirtualMachines \
  --name ScaleSetVM1 \
  --output table

# Then resize
az vm resize \
  --resource-group AZ104-VirtualMachines \
  --name ScaleSetVM1 \
  --size Standard_DS3_v2

If you want to be safe about it — especially in production — here’s a script that checks availability first and only deallocates if it needs to:[oneuptime]

bashRESOURCE_GROUP="AZ104-VirtualMachines"
VM_NAME="ScaleSetVM1"
NEW_SIZE="Standard_DS3_v2"

AVAILABLE=$(az vm list-vm-resize-options \
  --resource-group $RESOURCE_GROUP \
  --name $VM_NAME \
  --query "[?name=='$NEW_SIZE'].name" \
  --output tsv)

if [ -n "$AVAILABLE" ]; then
    echo "Resizing directly — no deallocation needed..."
    az vm resize --resource-group $RESOURCE_GROUP --name $VM_NAME --size $NEW_SIZE
else
    echo "Deallocation required. Stopping VM first..."
    az vm deallocate --resource-group $RESOURCE_GROUP --name $VM_NAME
    az vm resize --resource-group $RESOURCE_GROUP --name $VM_NAME --size $NEW_SIZE
    az vm start --resource-group $RESOURCE_GROUP --name $VM_NAME
fi

One more thing — if you’re thinking about jumping from v5 to v6 SKUs, that portal resize won’t work. The v6 series uses NVMe controllers instead of iSCSI, so you’ll need a redeploy for that path.[reddit]

Quick tip: SKU names ending in s (like D2s_v3) support Premium SSD. If storage performance matters, make sure your size supports it before resizing.

Adding Disks to a VM

At some point, your VM will run out of space, or you’ll want to separate your data from your OS disk. That’s when you attach a managed data disk.

I like to pre-create the disk first so I have full control over its settings, then attach it. Here’s how I set it up in the portal:

Disk name: scalesetvm1_datadisk2
Region: Same as the VM (this matters — you can’t attach across regions)
Source type: None
Size: 32 GiB
Key management: Platform-managed key

Then go to your VM → Settings → Disks → Attach existing disks, pick it, and assign it to LUN 1.

You can also create and attach a disk in one shot from the CLI:

bashaz vm disk attach \
  --vm-name ScaleSetVM1 \
  --resource-group AZ104-VirtualMachines \
  --name scalesetvm1_datadisk1 \
  --size-gb 32 \
  --sku Standard_LRS \
  --lun 0 \
  --new

The LUN number is just how the VM identifies each disk internally — LUN 0 for the first data disk, LUN 1 for the second, and so on. And yes, in most cases you can attach disks while the VM is running, which is great for production environments.[learn.microsoft]

Troubleshooting VM Networking

Network issues between VMs are frustrating, but they usually come down to a small set of culprits: NSGs, route tables, or a firewall rule inside the OS itself.

My go-to starting point is always Test-NetConnection. I’ll RDP into one VM, grab the private IP of the second VM from the portal, then run:

powershellTest-NetConnection 192.168.1.5 -Port 3389

If that succeeds, the VMs can talk to each other. If it fails, the next question is where traffic is being blocked.

This is where NSG layering trips people up. NSGs apply at two independent levels — the NIC and the subnet. Both are enforced, and both have to allow the traffic. I’ve seen cases where someone opens a port at the subnet level but forgets the NIC-level NSG still has a deny rule. Traffic gets dropped and nothing in the portal makes it obvious why.

And while we’re talking about port 3389 — please don’t leave RDP open to the internet. Use Just-in-Time (JIT) VM access instead. JIT keeps port 3389 blocked by default and only opens it temporarily for your specific IP when you request access through Defender for Cloud. It takes about five minutes to set up and dramatically reduces your exposure.[oneuptime]

Moving VMs Between Resource Groups

This one comes up whenever someone decides the resource group naming convention needs to change — which happens more than you’d think.

Moving is straightforward but has a few gotchas I’ve run into personally:

Create the target resource group first (e.g., AZ104-VirtualMachines-Migration)
Go to the source resource group → Overview → select all resources → Move → Move to another resource group
Wait for validation to pass — Azure checks compatibility before it does anything
Confirm and let it run

What I didn’t realize the first time: both the source and destination resource groups get locked during the move. You can’t create, update, or delete anything in either group while it’s in progress. The lock can last up to four hours, though most moves finish much faster.[learn.microsoft]

The VM itself stays running during the move — it doesn’t deallocate. And moving to a different resource group doesn’t change the VM’s Azure region. Location is permanent until you redeploy.[learn.microsoft]

A few things that can block the move:[learn.microsoft]

VMs in an availability set must all move together — you can’t move just one
VMs with Azure Backup enabled need backup paused first
VMs with Marketplace plans or disk encryption have extra steps

Always let the validation step run fully. It catches most of these issues before anything breaks.

Cheat Sheet

Task	Best Tool	Notes
Resize VM	CLI	Always causes restart; check deallocation need first
Attach new disk	CLI or Portal	Usually hot-attachable; no VM stop needed
Test VM connectivity	PowerShell (`Test-NetConnection`)	Check both NIC and subnet NSG levels
Secure RDP/SSH	JIT VM Access (Defender for Cloud)	Closes port by default, opens on-demand per IP
Move resource group	Portal	Both RGs lock during move; VM stays running