Back to BlogAzure Cloud

Azure Virtual Machine Troubleshooting Guide: 7 Fixes Every Beginner Should Know 2026

8 September 2026 6 min read
Photo by Campaign Creators on Unsplash

The core problem with Azure VM troubleshooting for beginners

Most people troubleshooting an Azure Virtual Machine (VM) for the first time panic because the error messages don't match anything they've seen before. A VM that was running fine yesterday is suddenly unreachable. The Azure portal shows one status, but the actual machine behaves differently. Without a structured approach, you'll click randomly through settings, change things that make it worse, and waste two hours when the fix was thirty seconds away.

This guide walks you through exactly where to start, what to check first, and when you actually need to escalate rather than spend more time digging.

1. Check the VM power state and allocation status

This is the most common reason VMs appear to be "down" but aren't actually broken.

In Azure Portal, open your Virtual Machine and look at the Status line. You're looking for two separate indicators:

  • Power state: shows "VM running" or "VM deallocated"
  • Allocation state: shows "allocated" or "deallocated"
  • What's the difference? A deallocated VM has been shut down but the disk still exists and you're not paying for compute (though you're still paying for storage). A running VM is active and ready. If your status shows "VM deallocated", the machine isn't responsive because it literally isn't running.

    How to fix it: Click "Start" at the top of the VM's overview page. Wait 60 to 90 seconds. The status will change to "VM running" and the allocation state will show "allocated".

    This solves roughly 30% of beginner VM issues. Seriously.

    2. Verify your network security group (NSG) rules

    If the VM is running and allocated but you still can't connect (via RDP on Windows, SSH on Linux), your firewall rules are blocking you.

    Network Security Groups act like a firewall. They sit between you and the VM and only allow traffic matching specific rules.

    What to check:

  • Go to your VM's Network settings
  • Find the associated NSG (listed under "Network interface")
  • Click it and open "Inbound security rules"
  • Look for a rule that allows port 3389 (Windows/RDP) or port 22 (Linux/SSH)
  • Check if the rule allows traffic from your IP address or from "0.0.0.0/0" (anywhere)
  • Common mistake: A default NSG allows nothing. You need to explicitly add a rule. Port 22 or 3389 won't be open by default, even though the VM itself is fine.

    How to fix it: Click "Add inbound security rule" and create one that allows:

  • Protocol: TCP
  • Destination port: 3389 (for Windows) or 22 (for Linux)
  • Source: Your IP address (if you're behind a static IP) or 0.0.0.0/0 if you need it open from anywhere
  • Wait a minute for the rule to activate. Try reconnecting.

    3. Verify the VM has a public IP address (if you need remote access)

    Some VMs are internal only and can only be accessed from within the Azure network. Others are meant to be publicly accessible. If you're trying to connect from outside Azure (from your laptop at home, for example), the VM needs a public IP.

    How to check:

  • Go to the VM's Network settings
  • Look for "Public IP address"
  • If it shows a real IP address (something like 20.x.x.x), you have one
  • If it's blank or shows "None", the VM isn't publicly accessible
  • How to fix it:

  • Go to Public IP addresses in your resource group
  • Create a new one if needed
  • Attach it to the VM's network interface
  • Wait a few minutes for Azure to propagate it
  • 4. Check the VM's OS-level firewall

    Even if network traffic reaches the VM, Windows Defender Firewall or Linux iptables might be blocking it.

    If you can get to the VM at all (or if you're troubleshooting a connectivity issue to an internal service), check the operating system's own firewall.

    Windows: Open Windows Defender Firewall and confirm that RDP (port 3389) is allowed in the inbound rules.

    Linux: Run `sudo iptables -L` to list rules, or check `sudo ufw status` if UFW is enabled.

    The fix varies by OS, but the principle is the same: the application or port you're trying to reach needs to be explicitly allowed.

    5. Review VM resource allocation and performance metrics

    A VM might be technically "running" but completely unresponsive because it's out of resources (CPU, memory, or disk space).

    How to check:

  • Go to the VM's Monitoring section (in the left menu)
  • Look at CPU percentage, Available memory, and Disk I/O
  • If CPU is constantly at 100% or memory is maxed out, the VM is resource-starved
  • What to do:

  • Identify which process is consuming resources (use Task Manager on Windows, `top` on Linux)
  • Stop unnecessary services or scale the VM to a larger size
  • If you're running out of disk space, you'll need to clean up or add additional disks
  • 6. Check the serial console for error messages

    If the VM is running but completely unresponsive to SSH or RDP, the serial console can show you what's actually happening at boot.

    How to access it:

  • Go to your VM in Azure Portal
  • Look for "Serial console" in the left menu
  • Select OS boot logs or click "Connect"
  • You'll see text output from the operating system's startup process
  • This is especially useful when the VM is stuck in a restart loop or won't boot at all. The serial console shows you exactly where it's failing.

    7. Use Azure's diagnostics and boot diagnostics

    Azure can automatically capture logs and screenshots of what the VM is doing.

    How to enable it:

  • Go to the VM's Diagnostics settings
  • Turn on "Boot diagnostics"
  • Select a storage account where logs will be saved
  • What you'll see:

  • Screenshots of the boot screen
  • Serial log output
  • Errors from earlier restarts
  • This is invaluable when troubleshooting VMs that won't boot or are crashing repeatedly.

    When should you escalate to your team?

    If you've worked through all seven steps and the VM still isn't responding, you've done the right investigation. Document what you've checked, screenshot the error messages or logs, and hand it over to a senior engineer. You've already ruled out 90% of common issues, which saves them hours.

    Learning to troubleshoot Azure VMs is one of the core skills you'll need as you move into cloud infrastructure roles. If you're planning a career move into Azure administration or cloud engineering, understanding these troubleshooting patterns now makes the difference between getting frustrated and actually progressing.

    The Azure Administrator Programme at SmoothOps 365 covers not just VM creation but real-world troubleshooting, network security, and performance tuning. If you're planning to move into this space and want structured, hands-on training, you can explore that on smoothops365.com/courses or book a free 2-hour live session to see how we teach cloud troubleshooting in practice: smoothops365.com/courses/it-helpdesk#free-session.

    Frequently asked questions

    What does "VM deallocated" mean and why does it matter?

    A deallocated VM is switched off and not consuming compute resources, so you're charged only for storage. You won't be charged for the VM's running time. When deallocated, the VM is completely unresponsive and won't answer any connection attempts. To use it again, you must click Start in the portal and wait for it to reach "VM running" status.

    How long should I wait before concluding a VM is actually broken?

    After starting a deallocated VM, wait 60 to 90 seconds for it to fully boot and allocate resources. If you've waited two minutes and still can't connect, move on to checking network rules. Don't assume it's broken within the first minute.

    Can I fix Azure VM issues without restarting it?

    Many issues (NSG rules, public IP assignment, firewall rules) can be fixed without restarting. Resource exhaustion and boot errors usually require a restart or VM resize. Always try non-destructive troubleshooting steps first, then restart if needed.

    What's the difference between a Network Security Group and the OS firewall?

    An NSG blocks traffic before it reaches the VM's network interface, like a perimeter fence. The OS firewall (Windows Defender Firewall or iptables) is on the machine itself and blocks traffic after it arrives. Both must allow your traffic for a connection to work.

    Where do I find error codes if my VM won't start?

    Check the Boot Diagnostics section in the Azure Portal for screenshots and serial logs. You can also look at the VM's Activity Log to see Azure-level errors. The serial console shows operating system level errors. Between those three, you'll find the root cause.

    Ready to start your IT career?

    SmoothOps 365 runs live instructor-led training every Saturday and Sunday. 3 months. 50 contact hours. Keep your job while you train.