Use ssh vmsw to complete work that requires a modern Linux software environment. It supplements the legacy system limitations of vmhw , but does not replace a commercial EDA host, and should not be used for ordinary file operations that can be reliably done locally.
Fixed environment
| Project | Information |
|---|---|
| SSH alias | vmsw |
| System | Ubuntu 24.04 LTS，x86_64 |
| User and home directory | mhliulgy，/home/mhliulgy |
| Authoritative workspace | Windows：D:\develop\Virtual Machines\Project；VM：/mnt/hgfs/Project |
| VM local scratch area | ~/temp/ |
| Shared temporary directory | /mnt/hgfs/Project/temp |
Commands verified as available include GCC/G++, Clang, CMake, Make, Python 3/pip, Git, Icarus Verilog, and Verilator. Tool installation and versions change; before actual execution, use command -v and version commands to verify the capabilities required by the task.
Host routing
- For compilation, builds, tests, scripts, Python environments, Git, text or data processing, and other modern Linux CLI work, use
vmsw。 - Open-source hardware assistant tools such as Icarus Verilog and Verilator can be used on
vmsw; for commercial EDA, license environments, and the lab's existing EDA versions, usevmhw。 - For hybrid tasks, do software-side preparation on
vmsw, execute dedicated EDA stages onvmhw, and hand off through the sharedProject. - Do not silently replace the commercial/legacy EDA flow in
vmhwwith open-source or newer tools; different implementations and versions may change results. - Do not have both VMs write to the same build directory at the same time. Use separate output directories per host or tool, for example
build-vmsw/andrun-vmhw/。
Workspace rules
Shared paths map as:
D:\develop\Virtual Machines\Project\<relative_project_path>
↕
/mnt/hgfs/Project/<relative_project_path>
Shared Project is the authoritative workspace. File search, viewing, and editing should preferentially be done on the Windows side; enter vmswonly when the task requires Linux behavior, tools, or dependencies. Artifacts generated by the VM should land back in the project directory under the same relative path.
Before starting execution, first verify the connection, directories, and required tools:
ssh -o BatchMode=yes vmsw "whoami; hostname; test -r /mnt/hgfs/Project/<relative_project_path>"
ssh -o BatchMode=yes vmsw "bash -lc 'cd /mnt/hgfs/Project/<relative_project_path> && command -v <command> && <command> <arguments>'"
If a project provides its own environment entry point, virtual environment, or container configuration, it should be loaded according to the project conventions first. Do not assume that interactive Shell aliases or initialization scripts are available in non-interactive SSH.
Dependencies and system operations
- Check existing tools and project lock files first; do not automatically execute
sudo、apt install, globalpip install, or system service modifications just because this Skill is invoked. - For Python projects, preferentially use the project's existing virtual environment; when creating a new environment, place it in the project's agreed location, and avoid mistaking a VM-specific binary environment for a cross-platform artifact.
- Before installing dependencies, upgrading the toolchain, modifying system configuration, or starting/stopping system services, confirm that the task truly requires it and that the corresponding authorization has been obtained.
- When using Ubuntu 24.04's
systemctl, modern compilers, or newer tools, still check whether the project requires other versions.
Long tasks and observation
For long tasks, close standard input and write to a task-specific log:
ssh vmsw "bash -lc 'cd /mnt/hgfs/Project/<relative_project_path> && nohup <command> > run.log 2>&1 < /dev/null &'"
ssh vmsw "pgrep -af '<process-pattern>'; tail -n 60 /mnt/hgfs/Project/<relative_project_path>/run.log"
Judge success based on the exit status, test results, expected artifacts, and logs together. Do not draw conclusions solely from the process ending or a single output file existing.
Exceptions to the shared mount
If a tool truly depends on Linux-native permissions, symlinks, file locks, or higher I/O performance, it may be temporarily stored locally on the VM:
ssh vmsw "mkdir -p ~/temp/<project_name>; cp -a /mnt/hgfs/Project/<relative_project_path>/. ~/temp/<project_name>/"
After completion, write the source code changes, reports, and artifacts that need to be kept back to the shared project. Use SCP only when the shared mount is unavailable:
scp <local_file> vmsw:~/temp/<project_name>/
scp vmsw:~/temp/<project_name>/<remote_file> .
Graphics programs and security
Use headless commands by default. Only when the user explicitly requests a graphical interface should you check for a remote desktop or use ssh -X vmsw <gui-command>; X11 forwarding requires that an X Server already be present on the Windows host.
vmsw 's Ubuntu desktop uses Xwayland. The currently verified desktop display is :0, but in a normal SSH session DISPLAY is empty, and merely setting DISPLAY=:0 will still fail due to missing authorization. Xwayland's authorization file is located at /run/user/1000/.mutter-Xwaylandauth.*; the specific filename varies with the desktop session and cannot be hardcoded.
When you need to display a GUI program launched by Make on the virtual machine desktop, first obtain the display number and authorization file from the running Xwayland process in the remote Shell, then export them to make and its child processes:
xwayland_args="$(ps -ww -C Xwayland -o args= | head -n 1)"
display_id="$(printf '%s\n' "$xwayland_args" | sed -n 's|.*Xwayland \(:[0-9][0-9]*\).*|\1|p')"
xauth_file="$(printf '%s\n' "$xwayland_args" | sed -n 's|.* -auth \([^ ]*\).*|\1|p')"
test -n "$display_id" && test -r "$xauth_file"
export DISPLAY="$display_id"
export XAUTHORITY="$xauth_file"
xdpyinfo >/dev/null 2>&1 && echo X11_OK
make <gui-target>
When running in the background, launch it in the same Shell where DISPLAY and XAUTHORITY have already been exported:
nohup make <gui-target> > gui-run.log 2>&1 < /dev/null &
Prefer setting export DISPLAY and XAUTHORITY in the environment before running Make. Do not just write make DISPLAY=:0: it neither provides the Xwayland authorization file, nor is a Make command-line variable guaranteed to become an environment variable for all recipe child processes.
If the task only requires batch processing, use the project's or tool's headless/batch mode. Consider xvfb-runonly when an offscreen X server is needed and the corresponding tool is already installed on the system; it will not display windows on the virtual machine desktop.
Xwayland authorization belongs to the current desktop user. When starting via sudo, switching users, or as a system service, you cannot assume the authorization is still valid; do not use the insecure xhost + to bypass access control.
Could not resolve hostname vmswIf it appears only in a restricted execution environment, retry according to the permission mechanism, and do not modify the user's SSH configuration without authorization.- By default, perform read-only probing first. Before deleting or overwriting results, terminating processes not belonging to this task, or modifying system-level state, you must confirm the target and authorization.
- Unless the user explicitly requests it, do not clean up the shared workspace or VM local directories.