network/ww.md

Wonderware Dev VM

Access

• Hostname: DESKTOP-6JL3KKO
• IP: 10.100.0.48 (VLAN 100 / LAN_100)
• OS: Windows 10 Enterprise (10.0.19045)
• Shell: PowerShell 7.6.1 (pwsh)
• Credentials: dohertj2 / Sonamu89 (local Administrator)
• Remote access: SSH (passwordless, key in C:\ProgramData\ssh\administrators_authorized_keys)
• Platform: ESXi VM (vmxnet3 vNIC)

Running Commands

ssh dohertj2@10.100.0.48 "hostname"
ssh dohertj2@10.100.0.48 "powershell -Command 'Get-NetAdapter | Format-Table -AutoSize'"

Default remote shell is pwsh 7.6.1. SCP/SFTP work normally.

Historical note (2026-04-28): the OpenSSH server originally shipped with DefaultShellCommandOption registry value set to the literal string "-NoLogo -Command" (single broken argument), which made every non-interactive ssh host <cmd> and SCP/SFTP fail. Fixed by setting it to -Command:

New-ItemProperty -Path 'HKLM:\SOFTWARE\OpenSSH' -Name DefaultShellCommandOption -Value '-Command' -PropertyType String -Force
Restart-Service sshd

Network Interface

Ethernet0 — vmxnet3 (ifIndex 6)

• MAC: 00-0C-29-F0-09-6C
• Speed: 10 Gbps
• IP: 10.100.0.48 (static)
• MTU: 1500
• Gateway: 10.100.0.1
• DNS: 10.100.0.1

Single vNIC, untagged on VLAN 100.

Display Adapters / GPU

The VM has an NVIDIA Quadro P1000 attached via PCI passthrough — full setup, attach procedure, and rollback are in ww_gpu.md. Adapter state inside Windows:

Adapter	Status	Why
NVIDIA Quadro P1000 (PCI\VEN_10DE&DEV_1CB1)	Active, 2560×1440	The intended display; drives DWM and serves NVENC for Parsec
VMware SVGA 3D (PCI\VEN_15AD&DEV_0405)	Disabled (PnP-disabled 2026-04-29)	Removing the second adapter is what got Parsec/DXGI to bind to the Quadro instead of falling back to MS Basic Render Driver. Re-enable with Enable-PnpDevice -InstanceId "PCI\VEN_15AD&DEV_0405&SUBSYS_040515AD&REV_00\3&61AAA01&0&78" -Confirm:$false
Parsec Virtual Display Adapter (ROOT\DISPLAY\0000)	Installed, offline (Availability=8)	Parsec ships this and host_virtual_monitors=1 is set in C:\ProgramData\Parsec\config.json, but it stays offline because the Quadro is already serving as the active display. Harmless; leave installed

Side effects

• vSphere VM Console window shows nothing — the Quadro doesn't render to ESXi's virtual framebuffer, and VMware SVGA (which did) is disabled. Use SSH / Parsec / RDP instead. If you need vSphere console access (e.g., to recover a black-screen Parsec failure), re-enable VMware SVGA via SSH first.
• NVENC session count is 1 max for typical workloads on the Quadro P1000. Parsec already holds the slot; OBS or another encoder using NVENC simultaneously won't get a session.

Remote desktop options

Path	Encoder	Notes
Parsec	NVENC (Quadro hardware H.264)	The intended remote-desktop path. Verified encoder = nvidia / codec = h264 in C:\ProgramData\Parsec\log.txt
RDP	Software (CPU AVC444)	Works, but Windows 10 client OS doesn't honor AVCHWEncodePreferred server-side, so NVENC stays idle for RDP. The three RDP GPU policies (bEnumerateHWBeforeSW, AVC444ModePreferred, AVCHWEncodePreferred) are all set under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services — bEnumerateHWBeforeSW is the only one that has visible effect on this OS (DWM uses the Quadro). The other two are no-ops on Win10 client SKUs but harmless
SSH	n/a	Always works; preferred for automation

Docker / WSL2 (removed)

As of 2026-04-28 this VM no longer runs Docker workloads. Docker Desktop, the docker-desktop WSL2 distro, and the VirtualMachinePlatform/WSL Windows features have been removed so a GPU can be re-attached via ESXi passthrough (Hyper-V/WSL2 was blocking it). A reboot is required to finalize the feature disable.

The lmxopcua project's Docker workloads now live on the docker host (10.100.0.35); see docker.md. The developer drives them from this VM via ~/bin/lmxopcua-fix.ps1, which SSHes into the docker host. A standalone Docker CLI (no daemon) is at ~/bin/docker.exe for ad-hoc remote operations against the docker host.

lmxopcua Project

• Path: C:\Users\dohertj2\Desktop\lmxopcua
• Local services: GLAuth (NSSM service, C:\publish\glauth\, port 3893), Galaxy / MXAccess, the OtOpcUa server itself (opc.tcp://localhost:4840)
• Remote services: SQL Server config DB at 10.100.0.35,14330 and all driver test fixtures via lmxopcua-fix.ps1
• Helper: ~/bin/lmxopcua-fix.ps1 — up/down/logs/ls/sync against /opt/otopcua-<driver>/ on the docker host
• Identifying label on remote containers: project=lmxopcua