ACA-Azure-Velo VM

Question

I was having issues earlier with the linux VM. I was not able to communicate to it and since it's used as a tunnel to other sites the other VMs were not pinging.

I know the East US DC was having issues but not sure if it affects this VM.

The only way to get connection back was to reboot the VM.

I would love some help to know if it's a network issue or a VM host issue.

Answer 1

To distinguish whether the outage was caused by VM host/platform issues or by networking, use a combination of platform diagnostics and in-guest/network checks.

1. Check for platform/host issues

• In the Azure portal, open the VM and use Diagnose and Solve problems (or the Boot diagnostics and Activity log) to see:
  • Any unplanned maintenance, storage-related forced shutdowns, or auto-recovery events around the time connectivity was lost.
  • Any VM reboot or redeploy events that were not initiated manually.
• Review the guidance on VM reboots: Azure may reboot VMs for urgent node or network switch maintenance, storage connectivity issues, or hardware problems. Storage-related forced shutdowns occur if disk connectivity is affected for more than 180 seconds; the VM is then powered back on when storage is healthy again. These are indicators of a host/platform-side issue rather than a guest/network misconfiguration.
• Also check the Azure Service Health dashboard for the East US region to confirm whether there was a regional incident impacting compute or storage at the time of the problem.

If platform logs show forced shutdowns, unplanned maintenance, or storage connectivity issues, this points to a VM host/platform issue.

2. Check for network path issues between VMs Since this VM is used as a tunnel and other VMs could not ping through it, validate the network path when the issue occurs again:

1. Verify basic connectivity between VMs

• From a source VM, use a TCP-based probe (for example, tcping) to the tunnel VM on the relevant port:

    tcping64.exe -t <tunnel VM address> <port>
  

• If this fails, it indicates a network path or guest firewall issue.

2. Validate NSG and routing

• On the tunnel VM’s NIC and subnet, confirm NSG rules allow:
  • Allow VNet Inbound and Allow Load Balancer Inbound defaults.
  • No higher-priority Deny rules blocking the required ports or protocols.
• Use Network Watcher → Connection troubleshoot (connectivity check) from a source VM to the tunnel VM. In the Hops section of the result, review any Issue type entries:
  • NetworkSecurityRule: indicates an NSG rule is blocking traffic.
  • UserDefinedRoute: indicates a route table or NVA is misrouting or dropping traffic.
  • Guest Firewall: indicates the OS firewall on the tunnel VM is blocking traffic.
  • DNS Resolution: indicates name resolution issues.
• Fix issues according to the connectivity check output (for example, adjust NSG rules, UDRs, or guest firewall).

If connectivity checks show NSG/UDR/guest firewall/DNS issues but no platform incidents, the problem is likely a network configuration or in-guest issue.

3. Check the VM itself (guest OS and performance)

• When connectivity is lost but the VM is still running, use tools like Azure Serial Console (for Linux/Windows) or existing management channels to check:
  • CPU and memory usage (to rule out resource exhaustion).
  • Whether the tunnel service or application is still listening on the expected ports.
• If the connectivity check flags CPU or Memory issues, follow the generic performance troubleshooting guidance for Azure VMs.

4. Use restart/redeploy only as recovery, not diagnosis

• Restarting the VM (as done) can temporarily clear both host and guest issues, so it does not by itself distinguish root cause.
• If problems recur and platform diagnostics show no host issues, consider redeploying the VM to a new node. Redeploy moves the VM to different hardware and can clear underlying host/network problems, but note that ephemeral disk data is lost and dynamic IPs may change.

5. Practical workflow for the next occurrence When/if the issue happens again:
6. Check Azure Service Health and the VM’s Activity log/Diagnose and Solve for host or storage incidents.
7. Run Network Watcher connectivity check from a source VM to the tunnel VM and review Issue type in the result.
8. Inspect NSGs, UDRs, and guest firewall based on the connectivity check.
9. If no network misconfiguration is found and platform logs show maintenance or storage-related shutdowns, treat it as a host/platform issue; if not, focus on the tunnel VM’s OS, services, and performance.

This approach will let you classify future outages as either network path/configuration issues or VM host/platform issues with evidence from Azure diagnostics.

---

References:

• Troubleshoot Azure VM connectivity problems
• Troubleshoot connectivity problems between Azure virtual machines
• Troubleshoot SSH connections to an Azure Linux VM that fails, errors out, or is refused
• Understand a system reboot for Azure VM
• Troubleshoot application connectivity issues on virtual machines in Azure

Answer 2

Thank you for reaching out Q/A and clearly explaining what happened. I understand how disruptive this would have been, especially since your Velo VM is acting as a tunnel and impacting connectivity for the dependent VMs.

Based on the behavior you described, there are two likely possibilities. One is a transient platform-level issue, particularly since you mentioned there were concerns in the East US region at that time. In such cases, the VM may remain in a running state but lose network connectivity at the host layer, and a reboot typically restores connectivity — which aligns with what you observed.

The second possibility is within the VM itself. It’s possible that the network interface or a background service (such as the tunneling process) became unresponsive. A reboot would reset these components and bring the system back to a healthy state.

As a starting point, I would recommend reviewing the Boot Diagnostics screenshot and logs from the Azure portal to confirm that the VM completed the boot process successfully and that there are no operating system-level errors during startup. This can help validate whether the OS and its services are functioning as expected.

Reference: How to use boot diagnostics to troubleshoot virtual machines in Azure https://learn.microsoft.com/en-us/azure/virtual-machines/boot-diagnostics

Please also check the VM Resource Health status in the Azure portal to verify whether any platform-related issues were reported during that timeframe.

Reference: https://learn.microsoft.com/en-us/azure/service-health/resource-health-overview

To further isolate the issue, you may use Azure Network Watcher to validate the network path. Tools such as Connection Troubleshoot or IP Flow Verify can help determine whether traffic is being allowed or blocked by network rules.

Reference: https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-overview

Additionally, it would be helpful to review VM metrics (CPU, memory, and network) around the time of the issue to rule out any resource constraints or unusual spikes.

Could you please check the private message and provide necessary details also provide below details:

1. What was the approximate time of the issue (UTC), and how long did the VM remain unreachable?
2. Was the VM completely unreachable, or were you able to access it via Serial Console / Run Command from the Azure portal?
3. Did this impact only external connectivity, or was internal VNet communication also affected?
4. Have there been any recent changes on the VM (updates, patches, configuration changes, or tunnel software modifications)?
5. Is this a one-time occurrence, or have you noticed similar connectivity drops in the past?
6. Are there any custom routing configurations (UDRs) or IP forwarding enabled on this VM since it is acting as a tunnel?
7. Do the system logs (syslog/dmesg) show any network, kernel, or service-related errors around the time of the issue?