Private corporate batches, live online cohorts and 1-on-1 mentoring in open-source hyperconverged infrastructure running virtual machines and containers on bare metal — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Harvester as a composed system rather than an appliance — what RKE2, KubeVirt, Longhorn, Multus and kube-vip each contribute, so a problem can be traced to the layer that owns it. The syllabus covers the full VM lifecycle including images, cloud-init, templates, live migration and node maintenance, then the areas teams underestimate: VLAN and storage network design, VM backup and restore to object storage, Rancher-driven guest cluster provisioning with the Harvester CSI and cloud provider, and the ISO-based upgrade path. Sessions run against real or nested hardware and include node failure and upgrade drills.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Harvester that means a trainer who has run it in production — open-source hyperconverged infrastructure running virtual machines and containers on bare metal — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Harvester batchHarvester is an open-source hyperconverged infrastructure platform that runs virtual machines and containers on the same bare-metal cluster. It installs from an ISO onto physical servers and gives you compute, storage and networking in one system — the role a traditional virtualisation stack plays, but built entirely from cloud-native components.
Underneath, Harvester is Kubernetes. The installer lays down an immutable Linux base and an RKE2 cluster, then assembles the platform from KubeVirt for virtual machines, Longhorn for replicated block storage, Multus and kube-vip for networking, and a management UI on top. That composition is not a detail: a Harvester VM is a KubeVirt VirtualMachine resource, its disk is a Longhorn volume, and its VLAN attachment is a Multus network. Anything you can do through the UI you can also do through kubectl or Terraform, which is what makes Harvester automatable in a way most virtualisation platforms are not.
In use it covers the things a virtualisation platform is expected to cover — VM images and templates, cloud-init and sysprep guest configuration, live migration, node maintenance mode, VM snapshots and backups to S3 or NFS, PCI and GPU passthrough — and adds a Kubernetes-native one: with Rancher integration, Harvester becomes a node driver, so guest RKE2 or K3s clusters can be provisioned directly onto it, complete with a cloud provider and a CSI driver that hands guest workloads Longhorn volumes from the host cluster.
Virtualisation licensing costs have been re-examined across the industry, and a lot of organisations are now genuinely evaluating alternatives for the first time in a decade. At the same time nobody is retiring their virtual machines — legacy applications, appliances, Windows workloads and databases will run in VMs for years yet, alongside the container platform the same team already operates.
That leaves an awkward middle: two platforms, two operational models, two skill sets, two procurement conversations. Harvester's proposition is to collapse them, running VMs and containers on one bare-metal cluster with one API and one management plane, and to make the VM layer as automatable as the container layer.
The skills required are genuinely hybrid, which is why teams struggle. A virtualisation engineer knows what live migration and VLANs and datastores mean but not what a CRD or a reconcile loop is. A Kubernetes engineer knows the control plane but has never sized a storage network, planned a rack for a hyperconverged cluster, or debugged PCI passthrough. Harvester needs both halves at once, and it needs them applied to real hardware decisions — network layout, disk choice, node count, upgrade windows — that are expensive to get wrong.
The composition, in detail, because every later troubleshooting session depends on knowing which layer owns a problem. What HCI means, what each embedded component contributes, and an honest comparison against a traditional virtualisation stack, OpenStack and plain KubeVirt.
Topics: Hyperconverged infrastructure: compute, storage and network on the same nodes · The Harvester stack: immutable base OS, RKE2, KubeVirt, Longhorn, Multus, kube-vip · A VM as a Kubernetes custom resource · Harvester vs traditional virtualisation vs OpenStack vs bare KubeVirt · Where Harvester fits: data centre, edge site, lab and branch · Sizing: node count, CPU, memory, disks and network interfaces · Support boundaries and version lifecycle
Getting from bare servers to a cluster you can support. Hardware and firmware prerequisites, the ISO install and its configuration file, node roles, the management VIP with DHCP or a static address, joining further nodes, and verifying the result properly.
Topics: Hardware, firmware and virtualisation extension prerequisites · ISO installation and the Harvester configuration file · Management and witness node roles, and quorum · The management VIP: kube-vip with DHCP or static addressing · Joining additional nodes with the cluster token · Automated and PXE-based installation for larger deployments · Initial settings, authentication and access control · Verifying cluster, Longhorn and KubeVirt health before use
The VM lifecycle end to end. Importing and building VirtualMachineImages, guest configuration with cloud-init on Linux and sysprep on Windows, reusable templates, then the operations that matter day to day — live migration, maintenance mode and scheduling.
Topics: VirtualMachineImage: URL import, upload and image storage · Creating VMs: CPU, memory, disks, interfaces and boot order · cloud-init for Linux guests and sysprep for Windows guests · Guest agent installation and what it enables · VM templates and versioned template management · Live migration: requirements, behaviour and failure cases · Node maintenance mode and evacuating a host · Scheduling, affinity rules and CPU and memory overcommit · Console access, serial console and troubleshooting a VM that will not boot
The area that causes most Harvester deployment failures and the hardest to change later. Management versus workload traffic, cluster networks and their uplinks, VLAN networks delivered through Multus, a dedicated storage network for replication, and load balancing for VMs and guest clusters.
Topics: Management network, cluster networks and network configuration per node · Uplinks, bonding modes and NIC layout · VLAN networks as NetworkAttachmentDefinitions via Multus · Attaching VMs to VLANs and untagged networks · The storage network and why Longhorn replication should be separated · kube-vip and the management VIP · Load balancer for VM and guest cluster services · MTU, jumbo frames and switch-side requirements · Diagnosing a VM with no connectivity, layer by layer
Longhorn as it appears under Harvester. Volumes and replica placement for VM disks, hot-plugging additional volumes, VM snapshots and what they do and do not protect, backup targets on S3 or NFS, restore in place and into a new VM, and capacity planning with replication overhead.
Topics: Longhorn under Harvester: replicas, disks and node storage · VM root and data volumes, and hot-plugging a volume · Volume expansion and live resize considerations · VM snapshots: crash consistency and what they cost in space · Backup targets: S3-compatible object storage and NFS · VM backup, restore in place and restore as a new VM · Cross-cluster VM restore for disaster recovery · Capacity planning with replica factor and snapshot growth · Degraded volumes, rebuilds and node failure behaviour
The capability that distinguishes Harvester from a plain hypervisor. Importing Harvester into Rancher, using it as a node driver to provision guest RKE2 and K3s clusters, and wiring the Harvester cloud provider and CSI driver so guest workloads get load balancers and persistent volumes from the host cluster.
Topics: Importing Harvester into Rancher and the multi-cluster view · The Harvester node driver and cloud credentials · Provisioning guest RKE2 and K3s clusters onto Harvester · Node pools, machine pools and guest cluster sizing · Harvester cloud provider: load balancer services for guest clusters · Harvester CSI driver: persistent volumes for guest workloads · Guest cluster upgrades and lifecycle from Rancher · Projects, namespaces, RBAC and multi-tenancy across host and guests · Resource quotas and preventing one tenant from starving another
Running the platform rather than demonstrating it. Driving Harvester with kubectl and the Terraform provider, the upgrade process and its prerequisites, PCI and GPU passthrough, air-gapped and edge deployment, monitoring and logging, and a structured troubleshooting order across the whole stack.
Topics: kubectl against Harvester: the resources behind every UI action · The Harvester Terraform provider for VMs, images and networks · Upgrade process, prerequisites and node-by-node behaviour · Upgrade rollback position and what to check before starting · PCI device and GPU passthrough, and vGPU considerations · USB passthrough and device management · Air-gapped installation and edge deployment patterns · Monitoring and logging: embedded stack and external integration · Structured troubleshooting: hardware, OS, RKE2, KubeVirt, Longhorn, network · Support bundles and what to collect before escalating
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall Harvester from ISO across multiple nodes, configure the management VIP, join the cluster and verify RKE2, KubeVirt and Longhorn health.
Build a VirtualMachineImage, add cloud-init and the guest agent, publish a template, then instantiate and live-migrate the resulting VMs.
Create cluster and VLAN networks over bonded uplinks, attach VMs across nodes, then separate Longhorn replication onto its own network and measure the effect.
Configure an S3 backup target, back up a running VM, then restore it as a new VM and separately into a second cluster.
From Rancher, provision a guest RKE2 cluster onto Harvester, expose a service through the cloud provider and attach a volume via the CSI driver.
Define VMs, images and networks in Terraform, upgrade the cluster with workloads running, fail a node, and produce the runbook and triage guide.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.