Diagnosing VM Connectivity Across Four Hosts with Multi-Agent Troubleshooting

ET Ducky's multi-agent troubleshooting runs an investigation across several machines from a single session. An operator describes a symptom in plain text. The system proposes a diagnostic command, runs it after operator approval, reads the result, and selects the next command based on what it found. This post documents one session that diagnosed a host-to-VM connectivity failure spanning four machines, and lists the commands, the configuration changes, and the verification step.

How a session runs

Each step is a single command targeted at one host. The command and its target host are shown to the operator before it runs, and it executes only after approval. The output returns to the session, which incorporates it and proposes the next command. A command runs on whichever host is relevant to the current hypothesis, so one session moves between machines as the investigation requires. Approval is per command, not per session, so an operator can decline or modify any individual step.

The reported symptom

The session opened with one statement:

I can't ping my virtual machines from the device running them.

The investigation spanned four hosts: the physical machine, ETDUCKY, and its virtual machines. The target VM was ETDUCKY-VM1 at 10.0.0.19; the host's Ethernet adapter was 10.0.0.101. Both are on the 10.0.0.0/24 subnet.

The investigation

The first command reproduced the symptom. A ping from the host to the VM returned 100% loss:

Pinging ETDUCKY-VM1.local [10.0.0.19] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.0.0.19:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Get-NetAdapter enumerated the interfaces present on the host: the physical Realtek 2.5GbE adapter (Ethernet, Up), two VMware adapters (VMnet1 and VMnet8, both Up), and a WSL Hyper-V switch. Get-NetIPInterface then showed IP forwarding was Disabled on the Ethernet adapter. The session enabled it with Set-NetIPInterface -Forwarding Enabled and re-ran the ping. The result was still 100% loss.

The session moved to ETDUCKY-VM1. ipconfig /all confirmed the VM's addressing: IPv4 10.0.0.19, default gateway 10.0.0.1, a current DHCP lease, and IP Routing Enabled: No. Inspecting the inbound firewall rules, the session found that the File and Printer Sharing echo-request rule, FPS-ICMP4-ERQ-In (Echo Request — ICMPv4-In), was disabled. With that rule disabled, the VM does not reply to ICMP echo requests. The session re-enabled it:

Set-NetFirewallRule -Name 'FPS-ICMP4-ERQ-In' -Enabled True

Returning to the host, the session checked IP forwarding on the two VMware adapters. Both were also Disabled:

InterfaceAlias                AddressFamily Forwarding
--------------                ------------- ----------
VMware Network Adapter VMnet1          IPv4   Disabled
VMware Network Adapter VMnet8          IPv4   Disabled

It enabled forwarding on both, then ran the ping a final time. The host received replies from the VM with no loss:

Pinging ETDUCKY-VM1.local [10.0.0.19] with 32 bytes of data:
Reply from 10.0.0.19: bytes=32 time<1ms TTL=128
Reply from 10.0.0.19: bytes=32 time<1ms TTL=128
Reply from 10.0.0.19: bytes=32 time<1ms TTL=128
Reply from 10.0.0.19: bytes=32 time<1ms TTL=128
Ping statistics for 10.0.0.19:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Configuration changed

Two changes were made during the session:

• On ETDUCKY-VM1: the inbound ICMPv4 echo-request firewall rule (FPS-ICMP4-ERQ-In) was re-enabled.
• On ETDUCKY: IP forwarding was enabled on the Ethernet, VMnet1, and VMnet8 interfaces.

Each change was verified by re-running the relevant query, and connectivity was confirmed by the final ping returning 0% loss.

Recommended follow-up

The session produced a written summary and a set of follow-up actions:

• Confirm the forwarding settings persist across a reboot with Get-NetIPInterface -AddressFamily IPv4 | Format-Table InterfaceAlias, Forwarding. If they revert, apply them through Group Policy or registry configuration rather than transient PowerShell commands.
• Export the VM's firewall rule state (Get-NetFirewallRule | Export-Csv) as a baseline, and audit which rules are intentionally disabled versus disabled by other software or misconfiguration.
• Establish a recurring connectivity check from both machines to the gateway (10.0.0.1) and DNS servers with Test-NetConnection to detect future routing or forwarding regressions.

Notes and limitations

The host and the VM are on the same 10.0.0.0/24 subnet. Delivery within a single subnet does not require IP forwarding, which routes between subnets, so the change that restored host-to-VM echo replies was re-enabling the VM's inbound ICMP rule. The forwarding changes were applied during the investigation and are not necessarily required for this specific same-subnet ping path; they are relevant when the host routes between its physical network and the VMware networks. An operator reviewing the session can see each command and result and decide which changes to keep.

The session interprets each command's output on the host where it ran and sequences across hosts, but it does not merge results into a single cross-host causal timeline; correlation is per host. Every command is shown before it runs, and approval is required for each, so the operator remains the control point for any change made to a machine.