Add remote hypervisor support (ESXi/vCenter/ws-shared)

[memoryforensics1]

Summary

VM and guest operations (vm_, guest_, screenshots, file transfer) can now target a VM on a remote hypervisor — ESXi, vCenter, or shared Workstation — instead of only the local VMware Workstation install.

Changes

• Config (ServerConfig.cs, appsettings.example.json): new Vm fields HostType (ws default / esx / vc / ws-shared / fusion / player), HostUrl (e.g. https://esxi-host/sdk), HostUsername, HostPassword.
• VmwareManager: the vmrun auth prefix (-T, plus -h/-u/-p for remote hosts) is built from config instead of the hardcoded -T ws on every call. Host config is validated fail-fast with LLM-friendly errors (remote type without URL, URL without credentials, URL with a local host type). UpdateTarget validates before mutating, so an invalid runtime switch leaves the previous target intact.
• vm_set_target: optional hostType/hostUrl/hostUsername/hostPassword parameters allow switching between local and remote hypervisors at runtime (omit to keep the current host, hostUrl="" to return to local).
• ESXi/vCenter quirk: the gui/nogui argument to vmrun start is omitted for server host types, which reject it.
• Log hygiene: -p/-gp/-vp password values are redacted (***) in vmrun debug logging — previously guest passwords were logged in full, and host passwords would have joined them.
• Test fix (pre-existing failure): UmdFrida_FailsWhenNotAttached expected umd_frida to require an attached Frida session, but the tool documents action="list" as working without attaching and each eval/inject spawns a fresh frida process. Rewrote the test to match the documented design.
• New tests: VmwareManagerHostConfigTests (10 tests) covering host config validation and runtime target switching.

Notes

• vmrun always runs locally, even against a remote hypervisor, so VMware Workstation/VIX must still be installed on the MCP host.
• For esx/vc, VmxPath is a datastore path like [datastore1] win10/win10.vmx.
• vmrun only accepts host credentials as CLI arguments, so the password is briefly visible in the local process list while a vmrun command runs (VMware constraint, documented in the config model).
• Kernel debugging (kd_*) is unaffected: KDNET was already network-based and independent of where the VM runs.

Testing

• dotnet build — clean, 0 warnings
• dotnet test — 136/136 pass (was 125/126 before: 1 pre-existing failure fixed, 10 tests added)

🤖 Generated with Claude Code