#  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.