Restoring Server Connectivity in a Virtualized Lab
A methodical layer-by-layer investigation of an unreachable server VM, tracing the fault from power state and console access through IP configuration, routing, and NetworkManager profile activation.
| Category | Linux Administration · Networking · Troubleshooting |
| Tools | Rocky Linux, nmcli, ip addr, ip route, Xen Orchestra, SSH |
| Role | Diagnosed and resolved the connectivity issue independently |
| Status | Resolved |
| Root Cause | NetworkManager connection profile existed but was inactive: no IP assigned to eth0 |
Initial Situation
The goal was to restore connectivity to a Wazuh SIEM server running in a virtualized lab after every connection attempt from the analyst workstation failed. The server at 172.22.3.49 was completely unreachable. Ping, SSH, and browser access all returned errors.
Every connection method failed from the Windows analyst PC (172.22.2.119):
The objective was not simply to restore access but to identify the root cause through methodical investigation. The failure could stem from any layer: the VM power state, network interface configuration, IP assignment, routing, firewall policy, or a failed service. Each possibility had to be systematically ruled in or out before applying a fix.
Initial Hypotheses
Before taking any action, several possible causes were considered:
- VM is powered off or in a suspended state
- VM is running but has no IP address assigned to its network interface
- Incorrect network interface configuration or missing routing table
- VLAN or subnet separation between the analyst workstation and the server
- VM attached to the wrong virtual network in the hypervisor
- Firewall policy blocking inbound connections
- Required service not running on the server
Rather than applying fixes at random, the investigation followed a structured layer-by-layer approach: power and VM state first, then network interface, then routing, then service availability. Each layer was confirmed before moving to the next.
Step-by-Step Investigation
Step 1. Verify connectivity from the analyst PC:
Step 2. Check the virtualization platform: Logged into Xen Orchestra (XOA), the hypervisor management interface. Located the server VM in the VM list.
Discovery: the VM was powered off. Started the VM through Xen Orchestra.
After the VM powered on, connection attempts still failed. A VM being powered on is not the same as being reachable on the network.
Step 3. Access the VM console: Opened the guest OS console directly in Xen Orchestra, bypassing the network entirely. Logged in as user shamar on Rocky Linux.
Step 4. Check network interface:
This confirmed the problem: the network interface existed and was recognized, but had no IP address.
Step 5. Check routing table:
Step 6. Check NetworkManager:
This was the key discovery. The network configuration was correct. The static IP, gateway, and DNS were all properly set. The profile simply was not active.
Root Cause
This is a common scenario in virtualized environments: a VM is cloned or restored from snapshot, or it reboots and the connection profile does not automatically activate. The interface exists, the config exists, but nothing connects them.
The Fix
After activating the profile, the server was immediately reachable from the Windows analyst PC. The dashboard became accessible at https://172.22.3.49.
Making the Fix Persistent
After verifying the fix worked, the server was rebooted to confirm the network would remain active. It did not. The same problem reappeared after reboot. The connection profile was not set to autoconnect.
With connection.autoconnect yes set, the NetworkManager profile activates automatically at boot. The server remained reachable after subsequent reboots.