ParaView Server

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting size. Scale the VM size and OS disk to the datasets that you want to visualise.

On your own workstation, install the ParaView 6.1.1 desktop client from paraview.org/download. The client and server versions must match, so use the same version as the server.

Configure the network security group (NSG) to allow inbound 22/tcp only, from your management network. Do not open port 11111 to the internet. You reach the server through the SSH tunnel, and this image binds the server to loopback, so it is not externally reachable in any case.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for ParaView Server by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) only.

Select Review + create, then Create. First boot initialisation takes a few seconds after the VM starts.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:paraview-server:default:latest
az vm create \
  --resource-group <your-rg> \
  --name paraview-server \
  --image sac1647283583153:paraview-server:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Do not run az vm open-port for 11111. The client reaches the server over the SSH tunnel in Step 7, not over an open port.

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

To look up the public IP at any time, run az vm show -d -g <your-rg> -n paraview-server --query publicIps -o tsv.

Step 4 - Verify the ParaView Server stack

Two systemd services make up the appliance. Confirm that both are active and that pvserver is bound to the loopback interface only:

systemctl is-active pvserver paraview-firewall ss -tln | grep ':11111 '

Both services report active, and the socket list shows pvserver on 127.0.0.1:11111, never on 0.0.0.0:

active active LISTEN 0 1 127.0.0.1:11111 0.0.0.0:*

Step 5 - Confirm the loopback-only security posture

The image binds pvserver to loopback and adds a firewall, so port 11111 is unreachable from outside the VM. Inspect the firewall rule and confirm that the VM does not serve the port on its own non-loopback address:

sudo nft list table inet sac_paraview
PRIMARY_IP=$(hostname -I | awk '{print $1}') timeout 4 bash -c "exec 3<>/dev/tcp/${PRIMARY_IP}/11111" 2>/dev/null \
  && echo "REACHABLE (unexpected)" || echo "port 11111 on ${PRIMARY_IP}: refused"

The firewall table drops any packet to port 11111 that does not arrive on lo. The connection to the non-loopback address is refused because pvserver listens on loopback only:

table inet sac_paraview { chain input { type filter hook input priority -5; policy accept; iif "lo" accept tcp dport 11111 drop } } port 11111 on 10.0.0.11: refused

Step 6 - Prove the headless render path

The image includes a self test. The test connects a pvpython client to the running pvserver, renders the sample dataset on the server through OSMesa, and asserts that the frame contains real content rather than a blank image. Run it:

sudo /usr/local/sbin/paraview-render-check.sh

The check confirms that the server is up on loopback and that the non-loopback port is refused. It also confirms that both a standalone pvbatch render and a pvpython client-to-server render produce a real, non-blank image:

render-check: pvserver bound loopback-only: LISTEN 0 1 127.0.0.1:11111 0.0.0.0:* render-check: loopback 127.0.0.1:11111 accepts (server up) render-check: non-loopback 10.0.0.11:11111 refused/filtered (secure) RENDER_OK mode=local -> /tmp/pv-check-local.png RENDER_OK mode=server -> /tmp/pv-check-server.png render-check: pvserver active, loopback-only, headless render non-blank (standalone + client/server) OK

Step 7 - Connect the ParaView desktop client over an SSH tunnel

pvserver is not exposed on the network, so you reach it with an SSH local forward. On your own workstation, open a tunnel that maps local port 11111 to the server's loopback port 11111:

ssh -N -L 11111:localhost:11111 azureuser@<vm-public-ip>

Leave the tunnel running. Then start the ParaView 6.1.1 desktop client and connect to the server:

File > Connect... -> Add Server Name: sac-pvserver Server Type: Client / Server Host: localhost Port: 11111 Configure -> Manual -> Save, then select the server and click Connect.

The client status bar shows that it is connected to a server. Open data on the server through the client's file browser (File > Open), for example the sample dataset /var/lib/paraview/sample/wavelet.vti. Apply a Contour filter and interact with the result. All rendering happens on the VM, and only the interface runs locally.

Step 8 - The per-VM instance info and sample dataset

Every VM writes an instance info file on first boot with its own connection instructions, and the sample dataset is ready to open. Inspect both, and the licence:

sudo cat /root/paraview-server-info.txt ls -la /var/lib/paraview/sample/ cat /usr/share/doc/paraview-server/LICENSE | head -5

The info file records the SSH tunnel command and the loopback-only posture. The sample directory holds wavelet.vti. The licence in the image is the BSD-3-Clause text with the Kitware copyright.

Step 9 - Load your own data

Copy your result sets to the VM, next to pvserver, and then open them through the connected client's file browser. From your workstation, run:

scp -r ./my-simulation-output azureuser@<vm-public-ip>:/var/lib/paraview/

For large or growing datasets, attach a dedicated Azure data disk, format it, and mount it with a UUID-keyed nofail fstab entry. Copy your data to the mount, and point the client's file browser at it.

ParaView reads the common scientific formats directly, including VTK/VTU/VTI/VTP, ExodusII, CGNS, netCDF/CF, HDF5 and XDMF.

Server Components

The image includes these components:

• ParaView Server (pvserver), version 6.1.1, at /opt/paraview/current/bin/pvserver
• pvpython and pvbatch (client and batch), version 6.1.1, in /opt/paraview/current/bin/
• OSMesa software OpenGL, the distribution's system library libOSMesa.so
• The generated sample dataset at /var/lib/paraview/sample/wavelet.vti

Filesystem Layout

The image uses this layout:

• / is the root filesystem
• /opt/paraview is the ParaView install, where current symlinks the versioned directory
• /var/lib/paraview/sample/wavelet.vti is the sample dataset in the image
• /usr/share/doc/paraview-server/LICENSE is the BSD-3-Clause licence (Kitware)
• /root/paraview-server-info.txt is the per-VM instance info that first boot writes
• /var/lib/sac/config/sac-paraview-nft.conf is the loopback-only firewall ruleset for port 11111
• /var/lib/sac/data/paraview-server-firstboot.done is the first boot bootstrap ready marker

Managing the service

systemctl status pvserver --no-pager sudo systemctl restart pvserver journalctl -u pvserver -n 50 --no-pager

Security

• pvserver runs as the non-root paraview service account, with no shell and no sudo.
• It binds 127.0.0.1:11111 only. A host firewall (paraview-firewall.service) also drops any non-loopback packet to port 11111, so the restriction is enforced twice.
• There is no default password or connect id. The VM's SSH authentication, through the tunnel, gates access.
• The pvserver unit is gated on the first boot bootstrap ready marker, so it does not serve before first boot completes.
• Keep 22/tcp limited to your management network. Do not open port 11111 to the internet.

Troubleshooting

The client cannot connect. Confirm that the SSH tunnel from Step 7 is still running and that systemctl is-active pvserver returns active on the VM. The client and server must both be ParaView 6.1.1, because the server refuses a version mismatch.

pvserver is not active. Inspect journalctl -u pvserver -n 100 --no-pager. The server starts only after the first boot marker exists at /var/lib/sac/data/paraview-server-firstboot.done.

A render is blank. Confirm that OSMesa is present with ldconfig -p | grep -i osmesa. The image ships libosmesa6. Re-run the self test in Step 6, which asserts that the rendered frame contains real content.

Support

For help, contact SecureAnyCloud support:

• Email: sales@secureanycloud.com
• Response time: 24/7, with a 24-hour response SLA
• Website: https://secureanycloud.com

Deploy on Azure

Launch ParaView Server 6.1.1 on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com