About

I am Tapas Kumar Mahanta. I work on storage and virtualization infrastructure, and I write down what breaks.

tapas@vmwareblogs:~$ whoami --verbose

  role       Senior Staff Support Engineer, Tintri by DDN
  based      Bangalore, India
  focus      vSphere internals, storage latency, automation
  vExpert    9 consecutive years
  posts      314 and counting
  method     reproduce it, break it, then write it down
9 years as a vEXPERT
VMware vExpert, 9 years vExpert Blogger vExpert Code Warrior VCAP-DCA 5.x VCP-DCV 5.x / 6.x / 8.x VCA Cloud / Workstation / DCV vRealize Operations Specialist AWS Solutions Architect CompTIA Server+ CompTIA Network+ CompTIA Linux+

What I actually do

My day job is the far end of a support escalation. When a customer’s platform is behaving in a way the documentation does not describe, the case reaches me. That means a lot of time inside vSphere internals, storage arrays, fabric configuration and the seams between them, which is where most difficult problems actually live.

Alongside that I build proofs of concept and internal tooling: CSI driver work for Kubernetes and OpenShift, OpenStack Cinder integration, log analysers that turn a support bundle into an answer, and migration tooling between hypervisors. Some of it ends up here.

Where I spend my time technically

  • vSphere and ESXi at scale. Hypervisor internals, vCenter services, cluster behaviour, and reading the errors whose text points at the wrong layer.
  • Storage. Tintri VMstore and vSAN, NFS and VMFS behaviour, snapshot chains, and tracing where the milliseconds actually go between guest, host, fabric and array.
  • Kubernetes and OpenShift on vSphere. CSI driver development, RWX volumes, KubeVirt, and the boundary where container storage meets an enterprise array.
  • Compute and fabric. Cisco UCS service profiles and interconnects, and the network faults that arrive disguised as storage faults.
  • Automation. PowerCLI, PowerShell and Python against the vSphere, SDDC Manager and Tintri APIs, because a report you run is worth more than a dashboard you watch.

Why this site exists

Most of what is published about this stack is either vendor documentation, which tells you how things are supposed to work, or a walkthrough that stops at the happy path. Neither helps at three in the morning when the thing in front of you is doing something the documentation does not admit is possible.

So the writing here is deliberately the other thing: the specific fault, how it was found, what the misleading symptom was, and what actually fixed it. If a walkthrough says something works, it is because it was run, broken, and run again.

Nothing here is official guidance. I do not speak for my employer or for any vendor. It is what worked in my hands, written down while it was still fresh. Corrections and disagreements are welcome and considerably more useful to me than agreement.

A reasonable place to start

Elsewhere