Post-Installation Notes

This is part of Installing a Data Processor in Proxmox VE (Cluster).

Preventing Clock Drift

No guest-side time configuration is required — KVM guests receive stable time from the paravirtualized kvm-clock source.

Ensure the Proxmox host itself synchronizes time via NTP (chrony is enabled by default):

chronyc tracking

Confirm the host reports a valid NTP source and a low offset.

Disabling Kernel Samepage Merging (KSM)

Proxmox VE enables Kernel Samepage Merging (KSM) by default. However, Stellar Cyber recommends that you disable it on the Proxmox host. KSM deduplicates identical memory pages across VMs, which only helps when memory is overcommitted. Stellar Cyber deployment does not overcommit memory — ballooning is disabled and VM memory is fully reserved — so KSM adds CPU overhead and latency to Elasticsearch without providing any benefit.

The following sample commands disable KSM in most implementations. Refer to your Proxmox documentation for details.

systemctl disable --now ksmtuned
echo 2 > /sys/kernel/mm/ksm/run

Notes on CPU Affinity and NUMA

Proxmox VE supports pinning a VM's vCPUs to specific host CPUs (qm set <vmid> --affinity <cpu-list>). This deployment does not use CPU affinity, for two reasons:

  • Memory locality cannot be preserved by pinning. The DLm is allocated 136 GB of RAM, which exceeds the memory local to a single socket on the reference host (approximately 128 GB). Pinning the DLm's vCPUs to one NUMA node would place part of its memory permanently on the remote node, while --numa 1 continues to advertise a two-node topology to the guest — causing the guest's own NUMA scheduler to optimize against a configuration that no longer reflects reality.
  • There is negligible contention to resolve. The two VMs consume 84 of the host's 88 threads. CPU affinity exists to stop workloads competing for the same physical cores; with the host almost fully allocated to two VMs and no third workload, the host scheduler manages placement effectively.

--numa 1 is enabled. Without pinning, it presents the guest with a topology consistent with its two-socket allocation, allowing the guest kernel to make sensible scheduling decisions.

If your host or allocation differs — for example, a VM whose memory fits within one socket, or a host running additional workloads — evaluate affinity against your own topology:

lscpu -e=CPU,NODE,CORE | sort -t, -k2 -n

Linux frequently interleaves hyperthread siblings across nodes; always use the actual lscpu output rather than assuming contiguous CPU ranges.

Next, see Troubleshooting Tips.