Mastering Netcup Server Control Panel (SCP): Cloud-Init, Edge Firewall, CoW Snapshots & REST API

Unlike simplified cloud portals that hide hypervisor internals behind opinionated wrappers, Netcup’s Server Control Panel (https://www.servercontrolpanel.de) exposes the underlying QEMU/KVM virtual machine configuration directly. Modern G12.5 instances instantiate on a PCIe-native QEMU machine model (pc-q35 topology rather than legacy pc-i440fx PCI bridges) with CPU mode set to host-passthrough, exposing the full host instruction set—including Zen 5 avx512f, avx512_vnni, avx512_bf16, aes-ni, and accurate L1/L2/L3 cache hierarchy descriptors—directly to the guest Linux kernel without translation overhead.

At provisioning time, SCP attaches a read-only virtual CD-ROM volume labeled cidata (/dev/sr0, ISO9660 filesystem) formatted for the Cloud-Init NoCloud datasource. This virtual media contains meta-data, user-data, and network-config payloads generated from the SCP UI or REST API. Under Server → Settings / General, administrators can inspect and tune three critical paravirtualized hardware buses prior to OS installation:

• ▪ Disk Controller (virtio-scsi vs virtio-blk): Always keep virtio-scsi enabled for modern Linux kernels (Debian 12, Ubuntu 24.04, Rocky Linux 9, Proxmox VE). It supports native SCSI UNMAP / TRIM discard pass-through (fstrim.timer) and multiqueue I/O scaling (num_queues mapped across your dedicated EPYC cores).
• ▪ Network Adapter (virtio-net with mq=on): Exposes paravirtualized 2.5 Gbit/s networking with vhost_net kernel acceleration, hardware TCP/UDP checksum offloading, and multi-queue RX/TX ring buffers that can be verified and scaled inside Linux via ethtool -l eth0 and ethtool -L eth0 combined 4.
• ▪ Boot Firmware (OVMF UEFI vs SeaBIOS): Official Netcup Cloud-Init templates boot via OVMF UEFI with GUID Partition Tables (GPT). Only revert to Legacy SeaBIOS if booting specialized legacy BSD or older custom recovery ISOs.

When provisioning a server under SCP → Media → Official Images, selecting any image marked with Cloud-Init unlocks the configuration editor. While Netcup automatically pre-fills basic network settings if left untouched, production deployments benefit from supplying explicit user-data and understanding how Netcup routes IPv4 and IPv6 traffic.

On Netcup’s network fabric, your primary IPv4 address typically sits on a shared /22 subnet (e.g., 255.255.252.0), while your dedicated /64 IPv6 block is statically routed through the link-local gateway fe80::1 (Router Advertisements / SLAAC are intentionally disabled so you maintain deterministic addressing and reverse DNS control).

Below is our production user-data YAML alongside the exact Netplan v2 configuration (network-config) for binding your primary IPv4 and multiple deterministic IPv6 addresses on Ubuntu 24.04 LTS / Debian 12:

#cloud-config
hostname: nc-prod-node01
fqdn: nc-prod-node01.example.com
manage_etc_hosts: true
timezone: UTC

package_update: true
package_upgrade: true
packages:
  - qemu-guest-agent
  - ufw
  - fail2ban
  - curl
  - jq
  - htop
  - iotop
  - unattended-upgrades

users:
  - name: opsadmin
    groups: [sudo, adm, systemd-journal]
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    lock_passwd: true
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIReplaceWithYourActualEd25519PublicKey opsadmin@secops

ssh_pwauth: false
disable_root: true

write_files:
  - path: /etc/ssh/sshd_config.d/99-netcup-hardening.conf
    permissions: '0600'
    content: |
      PermitRootLogin no
      PasswordAuthentication no
      KbdInteractiveAuthentication no
      X11Forwarding no
      MaxAuthTries 3
      AllowUsers opsadmin
  - path: /etc/sysctl.d/99-netcup-bbr.conf
    permissions: '0644'
    content: |
      net.core.default_qdisc = fq
      net.ipv4.tcp_congestion_control = bbr
      net.ipv4.tcp_fastopen = 3
      net.ipv6.conf.all.forwarding = 1

runcmd:
  - sysctl --system
  - systemctl enable --now qemu-guest-agent
  - systemctl enable --now fstrim.timer
  - systemctl restart ssh || systemctl restart sshd
  - ufw default deny incoming
  - ufw default allow outgoing
  - ufw allow 22/tcp comment 'SSH Admin'
  - ufw allow 80/tcp comment 'HTTP Ingress'
  - ufw allow 443/tcp comment 'HTTPS Ingress'
  - ufw allow 443/udp comment 'HTTP3 QUIC'
  - ufw --force enable
  - systemctl enable --now fail2ban

# Netcup Static IPv4 (/22) + Routed /64 IPv6 via Link-Local fe80::1 Gateway
network:
  version: 2
  ethernets:
    eth0:
      match:
        macaddress: "aa:bb:cc:dd:ee:ff" # Shown in SCP -> Network tab
      set-name: eth0
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 152.53.xxx.xxx/22             # Replace with your IPv4 & CIDR prefix from SCP
        - 2a0a:4cc0:xxxx:xxxx::1/64     # Primary IPv6 address from your /64 block
        - 2a0a:4cc0:xxxx:xxxx::2/64     # Optional secondary IPv6 for outbound mail/proxies
      nameservers:
        addresses:
          - 46.38.225.230               # Netcup Anycast DNS 1
          - 46.38.252.230               # Netcup Anycast DNS 2
          - 2a03:4000:0:1::e1e6         # Netcup IPv6 DNS
      routes:
        - to: default
          via: 152.53.xxx.1             # Your IPv4 Gateway from SCP -> Network
        - to: "::/0"
          via: "fe80::1"                # Netcup Standard IPv6 Link-Local Gateway
          on-link: true

One of the most valuable security upgrades in modern Netcup SCP is the Hypervisor Stateful Firewall (SCP → Network → Firewall).

On a standard Linux server running Docker or Kubernetes, publishing a container port with -p 5432:5432 inserts DNAT rules directly into the PREROUTING and DOCKER chains of iptables/nftables, bypassing ufw or firewalld INPUT rules and exposing your PostgreSQL or Redis container to external scanners.

Because the SCP Firewall operates outside your VM on the KVM host’s virtual switch port (tap device), packets blocked by your SCP Firewall policy are dropped at the hypervisor edge before they ever traverse the virtio-net ring buffer into your guest kernel. Even if a developer accidentally binds 0.0.0.0:6379 in docker-compose.yml, the SCP Edge Firewall drops external probes before they reach the VM.

Under the hood, the SCP Firewall maintains a stateful connection tracking (conntrack) table on the KVM host for each virtual interface. Outbound TCP, UDP, and ICMP flows initiated by your VM automatically permit return packets matching the ESTABLISHED,RELATED state without requiring explicit inbound open ports, though idle TCP connections without keepalives may age out if left silent across hypervisor state timeouts. For IPv6 (::/0), however, RFC 4861 Neighbor Discovery Protocol (NDP) operates via link-local multicast and unicast ICMPv6 packets (Types 135 Neighbor Solicitation and 136 Neighbor Advertisement) that are not tied to an outbound upper-layer flow—meaning explicit inbound ICMPv6 acceptance is required so the fe80::1 router can refresh your VM’s MAC-to-IPv6 neighbor binding.

Netcup SCP supports both Offline Snapshots and Online (Live) Copy-on-Write Snapshots, as well as exporting any snapshot as a compressed raw disk image over HTTPS for off-site disaster recovery.

When you trigger an Online Snapshot in SCP while qemu-guest-agent is active inside your Linux guest, KVM sends a guest-fsfreeze-freeze QMP command over the /dev/virtio-ports/org.qemu.guest_agent.0 character device. The guest agent executes all scripts in /etc/qemu/fsfreeze-hook.d/ with the freeze argument, invokes the Linux kernel FIFREEZE ioctl to flush filesystem dirty pages to disk, captures the atomic CoW block pointer in under 500 milliseconds, and immediately issues guest-fsfreeze-thaw.

When designing custom /etc/qemu/fsfreeze-hook.d/ scripts, keep execution latency strictly below 3 to 5 seconds. While FIFREEZE is active, all write syscalls (write(), fsync(), open(..., O_CREAT)) across the frozen guest filesystems block in uninterruptible sleep (D state). If a custom hook script hangs—for example, waiting on a deadlocked database connection or an unresponsive network mount—the QEMU QMP guest-fsfreeze-freeze call will exceed the hypervisor timeout, causing SCP to either abort the quiesced freeze (falling back to a crash-consistent block snapshot) or require an explicit sudo fsfreeze --unfreeze / via the VNC console if the guest agent process was killed mid-freeze.

#!/usr/bin/env bash
# Path: /etc/qemu/fsfreeze-hook.d/10-postgresql-checkpoint.sh
# Permissions: chmod 0755 /etc/qemu/fsfreeze-hook.d/10-postgresql-checkpoint.sh

set -euo pipefail

case "$1" in
  freeze)
    if systemctl is-active --quiet postgresql; then
      su - postgres -c "psql -U postgres -c 'CHECKPOINT;'" >/dev/null 2>&1 || true
      logger -t qemu-fsfreeze "PostgreSQL CHECKPOINT flushed prior to Netcup SCP CoW snapshot"
    fi
    ;;
  thaw)
    logger -t qemu-fsfreeze "Filesystem thawed after Netcup SCP CoW snapshot completion"
    ;;
esac

Netcup’s modern Server Control Panel exposes a full OpenAPI v1 REST interface (https://www.servercontrolpanel.de/scp-core/api/v1) secured by Keycloak OAuth2 OpenID Connect bearer tokens. You can explore the interactive Swagger UI directly at https://www.servercontrolpanel.de/scp-core/api/v1/swagger-ui/index.html.

Using the REST API, DevOps teams can query server telemetry, trigger graceful ACPI shutdowns, automate snapshot rotation before Ansible deployments, and programmatically update hypervisor firewall IP allowlists:

#!/usr/bin/env bash
# Authenticate against Netcup SCP Keycloak OIDC & Query Server UUIDs + Metrics
set -euo pipefail

SCP_TOKEN_URL="https://www.servercontrolpanel.de/realms/scp/protocol/openid-connect/token"
SCP_API_BASE="https://www.servercontrolpanel.de/scp-core/api/v1"

# 1. Exchange your SCP API credentials / refresh token for a short-lived Bearer Access Token:
ACCESS_TOKEN=$(curl -sS -X POST "$SCP_TOKEN_URL" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=scp" \
  -d "grant_type=refresh_token" \
  -d "refresh_token=${NETCUP_SCP_REFRESH_TOKEN}" | jq -r '.access_token')

# 2. List all Root Servers & VPS instances under your account:
curl -sS -X GET "${SCP_API_BASE}/servers" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Accept: application/json" | jq '.[] | {id: .id, name: .name, hostname: .hostname, status: .status}'

# 3. Create an Online Copy-on-Write Snapshot prior to maintenance:
SERVER_ID="123456"
curl -sS -X POST "${SCP_API_BASE}/servers/${SERVER_ID}/snapshots" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"name": "pre-upgrade-'$(date +%Y%m%d)'", "description": "Automated pre-Ansible CoW snapshot"}'