This is a staging copy of the PARASOL documentation, published for review before it goes live. Pages here may be unfinished, unreviewed or wrong, and they can change or disappear without notice.
This documentation is in draft and under active review. Figures for the Fall 2026 GPU reservation system are not yet published, and some pages describe behavior that has not been verified against a primary source. Confirm any figure with parasol@ucsd.edu before relying on it.
dsmlp-login.ucsd.edu is a login node for launching jobs and transferring
files. Running computation on it is prohibited.
Launching containers, requesting GPUs, running jobs that outlive a connection,
and attaching an editor all begin with an SSH connection to the login node:
Connect to the login node
ssh <username>@dsmlp-login.ucsd.edu
The username is the Active Directory (AD) username, which is the part of the
address before @ucsd.edu. The full address is not accepted. The password is
the AD password.
The VPN is not required for SSH to the login node. ssh to
dsmlp-login.ucsd.edu works from anywhere, on or off campus. An SSH tunnel or
the VPN is needed only to reach a port inside a container, such as a Jupyter
server started by a launch script.
dsmlp-login.ucsd.edu is a jumpbox. It is for launching containers on cluster
nodes, moving files, and managing running work. Running work on it is
prohibited.
Use
Tools
Launching containers
launch.sh and its wrappers
Moving files in and out
scp, sftp, rsync, git
Managing running work
kubectl get pods, kubectl delete pod, and kubesh to enter a running container
Small housekeeping
Listing directories, checking disk usage, editing a config file, reading a log
Manual job execution on dsmlp-login is prohibited by policy. Prohibited work
includes Python scripts, Java projects, notebooks, training runs, and data
conversions.
Running an editor's server component on dsmlp-login is not permitted. Running
VS Code directly on the login node is specifically prohibited. The supported
configuration places VS Code in a container. See
Remote Editor Setup.
Remote editors are stopped automatically
Automated jobs find and stop VS Code and other remote-editor processes on the
login node.
CPU-intensive work on the login node is throttled to at most 10% of one CPU
core, so it runs slowly. Move work that runs slowly there into a container. Do
data processing, compiling, and debugging in a container. See
Running Work in a Container.
Each container is assigned CPU, RAM, and GPU of its own and is isolated from
other users' processes. The login node is shared: the resources one session
uses there are taken from every other user signed in.
Every user passes through the login node. A loaded login node degrades
launching for everyone signed in, not only for one job.
Many CPU cores, tens of gigabytes of memory, and a GPU are available on the
cluster nodes through a launch script.
A launch runs in one of three modes, depending on whether the session is
attended:
Interactive, background, and batch launches
launch-scipy-ml.sh -W <WORKSPACE> # interactive: a shell in a container
launch-scipy-ml.sh -W <WORKSPACE> -b # background: keeps running after a disconnect
launch-scipy-ml.sh -W <WORKSPACE> -B -- python train.py # batch: runs to completion, then exits
The login node and the container share a filesystem. A file copied to the
login node with scp is in the container, and a file a job writes is on the
login node once the job is over. No copying step is needed between them.
An SSH key pair removes the password prompt from repeated connections. Generate
a pair on the local machine and install the public key on the login node:
Naming the key type with -t fixes the file name, which the second command
must match. The type a bare ssh-keygen picks has changed between OpenSSH
releases.
To verify the key, connect again. A connection that does not ask for the AD
password is using the key. The key's own passphrase is still requested if one
was set.
A remote editor requires a key pair. VS Code connects through a ProxyCommand
that cannot prompt for a password, and the editor's connection terminates
inside the container rather than on the login node. launch.sh -H carries the
key installed on the login node into the container at launch.
The Key Pair covers the Windows commands,
the local file permissions, the SSH agent, and the IdentityFile directive.
kubesh, run on the login node, opens a second shell in a running container
without starting a second container:
Run on the login node
kubectl get pods # find the pod
kubesh <pod-id> # enter it
This is the supported way to watch a job that is already running. A second
launch starts a second container with its own resources rather than attaching
to the first.
A Jupyter server or any other service listening inside a container is not
directly reachable from a personal machine. Two SSH tunnel forms reach it, and
they target different ports. The two forms are not interchangeable. Using the
wrong form is the usual reason a tunnel does not work.
To reach
Use
A port the launcher published on the login node, such as the port in the Jupyter URL
http://localhost:8889/user/<username>/tree/ then opens the session, and the
token from the launch output authenticates it. Replacing tree with lab in
that URL opens JupyterLab, which adds a terminal and an editor.
-N means "no command", so a working tunnel prints nothing. A silent terminal
indicates success, not a hang. Keep the terminal open for as long as the tunnel
is needed. Ctrl+C closes the tunnel.
Closing a tunnel does not stop the container. Stopping the container does not
close the tunnel. At the end of a session, quit Jupyter or exit the
container, then press Ctrl+C in the tunnel's terminal.
Warning
A container that has only been disconnected from may still be running and
still holding a GPU.
With a connection to the campus VPN, the launch URL works as printed and no
tunnel is required. Either route works. The VPN involves fewer steps to
remember. A tunnel involves less to install and does not route the rest of the
machine's traffic through campus.
A tunnel or the VPN is needed only for container ports, such as a Jupyter
server started by launch.sh. Neither is needed for ssh to the login node or
for Datahub in a browser.
kubectl port-forward connects the login node to a port inside a pod. It
covers the case where the container publishes nothing itself, such as a custom
image with an overridden entrypoint:
An incorrect username format. Use username, not username@ucsd.edu, with the AD password.
The connection hangs after the password
Duo approval is still pending on the phone.
Connection timed out from off campus
A network that blocks outbound SSH, such as a hotel, a conference, or some corporate networks. The VPN is not required for ssh, but connecting to it routes around a block of this kind.
A host key warning
Do not accept it without checking. Where no change was announced, contact parasol@ucsd.edu before removing the stored key.
A tunnel that refuses the connection, or a browser that does not load the
forwarded page, usually has one of two causes:
The local port is already in use, often by a tunnel left open in another
window. lsof -i :8889 names the process. Stop that process or choose a
different local port.
The remote port is wrong. The port in a Jupyter URL is assigned at launch
and is unlikely to be the same twice. The current launch output carries the
current port. A command from an earlier session does not.