Author: Danilo Chiacchio
Infrastructure Engineer with hands-on experience in virtualization, Linux, Windows Server, and enterprise infrastructure troubleshooting. I work with real-world infrastructure environments and technical labs, focusing on diagnosing problems, understanding root causes, and documenting practical solutions. DPC Virtual Tips was created to share hands-on troubleshooting guides, lab experiences, technical procedures, and lessons learned while working with technologies such as VMware, Linux, HPC/Slurm, networking, storage, and infrastructure automation with Python.
Keeping time synchronized across Linux servers is especially important in environments where authentication, logging, monitoring, distributed applications, and cluster services depend on consistent timestamps. In this guide, I will use Ansible to manage the Chrony configuration across multiple Linux systems in my HPC lab. Instead of manually editing /etc/chrony.conf on each server, we will use an Ansible inventory, group_vars, a Jinja2 template, handlers, and an automated synchronization check. The final workflow will: Lab Environment The lab used for this guide contains: I use root access in this lab for simplicity. For production environments, I recommend using a dedicated automation account…
Troubleshoot packet drops on ESXi by first identifying where packet loss occurs in the virtual and physical network path. A problem that appears to involve a physical NIC may actually be caused by a virtual switch, VMXNET3 queue, CPU contention, VLAN configuration, MTU mismatch, or an upstream physical switch. The first goal is not to collect every possible counter. It is to identify where packets enter the host, where they should leave, and at which point the counters or captures stop matching. This prevents unnecessary changes and helps separate an ESXi problem from a guest operating system or physical network…
Slurm job submission is a fundamental task for users working with High Performance Computing (HPC) clusters. In this guide, I will demonstrate the basic commands used to submit jobs, including srun for interactive execution and sbatch for batch processing. When working with a Slurm-managed cluster, users do not usually execute workloads directly on compute nodes. Instead, they request resources from the scheduler, which allocates nodes, CPUs, and execution time according to the job requirements. This article provides practical examples of job submission in a Slurm environment, showing how to run commands interactively, submit scripts, inspect the queue, and understand the…
VMware NSX overlay networking uses Tunnel Endpoints (TEPs) to carry Geneve-encapsulated traffic between transport nodes. ESXi hosts and NSX Edge nodes need reliable IP connectivity across the underlay network for these overlay tunnels to remain healthy. When overlay traffic fails, one of the first checks is to verify TEP-to-TEP connectivity, MTU, and the tunnel path from both the ESXi host and the Edge node. In this lab, I will show the commands I use to validate that path from both sides. Let’s Look Inside an Edge-VM In the below picture, we can see a diagram showing the details of the…
Building a Slurm cluster in a lab is one of the best ways to understand how the controller, compute nodes, authentication, accounting, storage, and user environment work together. In this guide, I will document the Slurm environment I built using virtual machines running on a physical VMware ESXi host. This is not intended to be a production reference architecture. The goal is to create a functional environment where I can test Slurm administration, job submission, troubleshooting, accounting, and automation. The lab includes redundant Slurm controllers, dedicated accounting with slurmdbd, shared user home directories, login nodes, and multiple compute nodes. Lab…
vCenter Server continuously monitors communication with the ESXi hosts that it manages. As part of this communication, the vpxa agent running on an ESXi host sends heartbeat packets to vCenter Server over UDP port 902. Under normal conditions, these heartbeat packets are transmitted approximately every 10 seconds. If vCenter Server does not receive a heartbeat within its configured timeout window, the ESXi host can transition to a Not Responding state in the vSphere Client. Current Broadcom guidance describes the default timeout window as approximately 60 seconds, meaning that multiple consecutive heartbeat messages must be missed before the host is marked as unavailable. The important point is…