linux virtual machine agent status is not ready.

Question

I always suffer from linux virtual machine agent status is not ready. And I can not ssh to the vm. Restart the linux vm solve the problem. But one day later, the problem appear again. It is pretty annoying. Any idea how to solve the problem permantly?

Answer 1

chaowen guo

Microsoft documentation and multiple customer cases confirm that recurring “Agent Not Ready” on Linux VMs is typically caused by one or more of the following:

Azure Linux Agent (walinuxagent) is unstable, stopped, or corrupted - This often happens after OS patching, cleanup activities, or removal of required Python dependencies, which the Azure Linux Agent depends on. When the agent crashes or fails to start properly, Azure loses communication with the VM, leading to SSH failures and Agent Not Ready status. - https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/linux-azure-guest-agent

Agent auto‑update is disabled - If AutoUpdate.Enabled is not enabled in waagent.conf, the agent can become outdated or unstable after OS updates, causing repeated failures.

Low‑memory / burstable VM sizes (B‑series) - Microsoft has confirmed that B‑series VMs can intermittently enter an Agent Not Ready state under memory pressure, even when CPU usage appears normal. This is a known and documented behavior.

Blocked outbound connectivity to Azure infrastructure IP - The Azure Linux Agent must communicate with 168.63.129.16 (Azure Fabric Controller). If this IP is blocked by OS firewalls or routing rules, the agent will fail and show Not Ready.

To permanently resolve this issue and prevent recurrence, Microsoft recommends the following corrective actions:

Reinstall and stabilize the Azure Linux Agent

1. Reinstall walinuxagent
2. Ensure required Python packages are present
3. Restart the agent service
4. This is the primary fix when the issue repeatedly reappears after reboot.
5. Enable Azure Linux Agent auto‑update
6. Verify AutoUpdate.Enabled=y in /etc/waagent.conf
7. This prevents agent drift and instability after OS updates.
8. Review VM size

If the VM is on a B‑series SKU, consider resizing to a non‑burstable VM with sufficient memory. Microsoft confirms this resolves repeated Agent Not Ready conditions caused by memory starvation.

Validate outbound connectivity - Ensure 168.63.129.16 is not blocked at OS firewall or routing level

This IP is mandatory for agent health and VM management.

A restart temporarily resets the Azure Linux Agent process, which restores SSH access for some time. However, once the VM hits the same underlying condition (agent crash, dependency issue, or memory pressure), the agent fails again, and the issue reappears. This behavior is expected until the root cause is corrected - https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/linux-azure-guest-agent

Answer 2

To permanently fix recurring "VM agent status is not ready" and SSH issues on an Azure Linux VM, focus on the Azure Linux Agent health and its connectivity to the Azure Fabric Controller.

1. Verify and stabilize the Azure Linux Agent service
   • Connect when the VM is reachable (or via Serial Console if SSH is down).
   • Check the agent service status (service name is typically walinuxagent or waagent). If it is running but unstable, restart it; if stopped, start it and monitor:
     • Ensure it stays running over time (check after several hours or next day).
   • Confirm auto-update is enabled so the agent stays on a supported version. In /etc/waagent.conf:

          AutoUpdate.Enabled=y
     

   • If the agent version is old or unsupported, update it as described in How to update the Azure Linux Agent on a VM.
2. Ensure required connectivity to Azure Fabric Controller
   • The Azure Linux Agent must reach the Fabric Controller on IP 168.63.129.16. If this IP or required ports are intermittently blocked, the agent repeatedly goes to "Not Ready" and extensions/SSH-related operations fail.
   • From the VM (as root), test connectivity:

          curl http://168.63.129.16/?comp=versions
     

   • If the command fails or times out, check:
     • Local firewall rules (iptables, firewalld, or third‑party firewall) to ensure outbound access to 168.63.129.16 on ports 80, 443, and 32526 is allowed.
     • That no proxy or network security configuration is blocking this IP. This IP is a special Azure virtual public IP and must not be blocked.
3. Use agent logs to identify recurring failures
   • Review /var/log/waagent.log for repeated warnings or errors, especially around times when the status flips to "Not Ready".
   • Look for messages about failure to retrieve goal state or inability to connect to 168.63.129.16. If present, that confirms a connectivity or firewall issue that must be fixed rather than masked by reboots.
4. Address SSH unavailability separately if needed
   • If SSH is also failing, use Azure Serial Console or Run Command to repair OS-level issues (for example, filesystem errors, Hyper‑V NIC/MAC issues, or SSH directory permissions) as described in the SSH and boot troubleshooting articles. However, the recurring "agent not ready" symptom is most often due to:
     • Outdated or misconfigured Azure Linux Agent, and/or
     • Blocked connectivity to 168.63.129.16.

Once the Azure Linux Agent is on a supported version, configured with AutoUpdate.Enabled=y, and has stable connectivity to 168.63.129.16 on the required ports, the "VM agent status is not ready" condition should stop recurring without needing daily reboots.

---

References:

• Troubleshoot the Azure Linux Agent
• Troubleshoot SSH connections to an Azure Linux VM that fails, errors out, or is refused
• Troubleshoot Linux virtual machine boot issues due to filesystem errors
• Troubleshoot Linux virtual machine boot and network issues due to Hyper-V driver-associated errors
• Troubleshoot SSH connection issues in Azure Linux VM due to permission and ownership issues
• Troubleshoot Azure VM extension issues