FIELD NOTES ON VIRTUALIZATION, STORAGE AND INFRASTRUCTURE
Written from production, not from datasheets.
Three hundred and fourteen posts on vSphere internals, storage latency, automation and the failure modes that only show up at three in the morning. If a walkthrough here says something works, it is because it was run, broken, and run again.
tapas@vmwareblogs:~$ site --summary
author Tapas Kumar Mahanta, Solutions Architect
focus vSphere, storage, automation, infrastructure
posts 314
subjects 6
linkedin /in/tapas-kumar-mahanta
method reproduce it, break it, then write it down
tapas@vmwareblogs:~$ _
Credentials
Recognised in the VMware vExpert programme every year since 2017, for the writing on this site and the tooling behind it.
WHAT YOU WILL FIND HERE
vSphere and ESXi
Hypervisor internals, vCenter services, cluster behaviour, and the errors whose text points you at the wrong layer.
172 posts
Storage
vSAN, Tintri arrays, NFS and VMFS behaviour, snapshot chains, and tracing where the milliseconds actually go.
74 posts
Automation
PowerCLI and Python that replace repeated clicking, with the scripts written out in full rather than summarised.
97 posts
Compute and networking
Cisco UCS fabric, service profiles, and the network faults that arrive disguised as storage faults.
28 posts
Containers and cloud
Kubernetes, container runtimes and AWS, mostly at the point where they meet on premises infrastructure.
8 posts
Operations
Monitoring pipelines, backup platforms and Hyper-V, the systems that live alongside a vSphere estate.
11 posts
LATEST POSTS
-
VCF from the ground up, part 5: prechecks, bundles and upgrades, and reading a failed precheck properly
The upgrade dependency chain, why prechecks fail on things that look unrelated, and a Python driver that runs check sets, groups failures…
-
VCF from the ground up, part 4: workload domain design, and the decisions you cannot walk back
NSX cluster sharing, SSO domain joins and their allocation ceilings, stretched clusters that block removal. The irreversible choices, why the API enforces…
-
VCF from the ground up, part 3: network pools and commissioning hosts at scale
Network pools come first and constrain everything after. The IP pool validation rules, the 1-to-50 commissioning limit, and a batched commissioner that…
-
VCF from the ground up, part 2: bring-up with Cloud Builder, and what each validation is actually testing
Validate before you build. The Cloud Builder spec, the validation loop, and the checks that fail most often, with a Python driver…
-
VCF from the ground up, part 1: the two control planes, the token model, and the prerequisites that actually fail bring-up
Cloud Builder and SDDC Manager are different APIs with different authentication. Token lifetimes, the 404 that means an expired refresh token, resource…
-
The Tintri PowerShell Core Toolkit 5.1: the real cmdlet surface, and the snapshot lifecycle done with it
158 cmdlets, the parameters that actually exist, the fleet primitive most people miss, and what the toolkit deliberately cannot do. Plus a…
-
Tintri snapshot scripting done properly: fullApiVersion, the Page object, filters and snapshot locking
Version negotiation belongs in the login body, not the URL. Paginated snapshot audits with documented filters, the lock and unlock APIs, and…
-
A daily Tintri fleet sweep: every VMstore and TGC in one report
Per-appliance UIs answer per-appliance questions. This polls the whole estate concurrently for unacknowledged alerts, component health, capacity runway and replication lag, and…
See all 314 posts organised by subject
ABOUT ME
I am Tapas Kumar Mahanta, a Solutions Architect working on storage and virtualization infrastructure, based in Bangalore. Most of what appears on this site starts as a customer escalation, a lab build or a proof of concept that did not behave the way the documentation said it would.
The day job covers vSphere and ESXi at scale, Tintri and vSAN storage, Cisco UCS, Kubernetes and CSI driver development, and OpenStack and OpenShift integration work. The writing here is the residue of that: the specific thing that was wrong, how it was found, and what to do about it.
Nothing here is vendor approved and none of it is official guidance. It is what worked, written down while it was still fresh. Corrections and disagreements are welcome, and more useful to me than agreement.