Unable to Access Linux VM — How We Diagnosed and Recovered It ?
The Ticket
It started with a straightforward request — "Unable to access Linux VM."
No error message. No context. Just a server that wasn't responding. As an Azure Admin, this is one of the most common tickets you'll receive — and the key is to follow a systematic process rather than jumping straight to conclusions.
Step 1 — Try Access from the Jump Server
The first thing we always do is rule out the obvious.
We logged into our Jump Server (the secure bastion host we use to access VMs internally) and attempted to SSH into the Linux VM from there.
Result: Connection failed. The VM was not reachable from the jump server either — so this wasn't a local network or VPN issue on the user's side. The problem was with the VM itself.
Step 2 — Check if the VM is Running
Before panicking, check the basics. We went to the Azure Portal and checked the VM status.
Azure Portal → Virtual Machines → [VM Name] → Overview
Result: VM was showing as Running.
This was an important clue. The VM was powered on and Azure believed it was healthy — but something inside the OS was wrong.
Step 3 — Check Serial Console
Since the VM was running but unreachable, we opened the Azure Serial Console to look directly at what was happening inside the VM without needing a network connection.
Azure Portal → Virtual Machines → [VM Name] → Serial Console
What we saw immediately told us the story — the console output showed that the CPU was stuck.
This is a classic sign that the VM's operating system has hung — the kernel or a process has locked up, consuming the CPU and making the system completely unresponsive. No new connections can come in, no commands can run, and the OS is essentially frozen.
Step 4 — Raise Approval on the Ticket
In any professional environment, you never reboot a production server without approval.We have received approval within 15 min as it is a production server.
Step 5 — Reboot the VM
With approval in hand, we performed a restart from the Azure Portal:
Azure Portal → Virtual Machines → [VM Name] → STOP→START
We monitored the Serial Console during the reboot to watch the boot sequence in real time.
The VM booted cleanly — no errors, no missing files, no kernel panic.
Step 6 — Verify SSH Access
Once the VM was back up, we went back to the Jump Server and attempted SSH again.