Private corporate batches, live online cohorts and 1-on-1 mentoring in hypervisors and the hardware they abstract — KVM, Hyper-V, ESXi, live migration, and where containers and microVMs fit — 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 virtualization from the hardware extensions upward: how VT-x, EPT and IOMMU make near-native execution possible, how memory overcommit and ballooning actually behave under pressure, how storage image formats and snapshots trade space against performance, and how virtual switching and SR-IOV change the network path. The hands-on work is built on KVM, QEMU and libvirt with Hyper-V and ESXi compared alongside, and includes live migration, nested virtualization and a direct comparison of the same workload as a virtual machine, a container and a microVM.
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 Virtualization that means a trainer who has run it in production — hypervisors and the hardware they abstract — KVM, Hyper-V, ESXi, live migration, and where containers and microVMs fit — 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 Virtualization batchVirtualization is the technique of presenting one set of physical resources as many independent logical ones. A hypervisor sits between hardware and guest operating systems, gives each guest the illusion of owning a processor, memory, disks and network interfaces, and arbitrates the real hardware underneath. The guest kernel believes it is running on a machine; the hypervisor decides what that actually means.
The mechanics are worth knowing because they explain almost every performance question that follows. Hardware extensions — Intel VT-x and AMD-V for the processor, EPT and NPT for memory translation, IOMMU for device assignment — let most guest instructions run natively and trap only the privileged ones, which is why a modern virtual machine costs a few percent rather than an order of magnitude. Memory is overcommitted through ballooning and page sharing, storage is abstracted into image formats with thin provisioning and copy-on-write snapshots, and the network is rebuilt in software as bridges, virtual switches and overlays. Type 1 hypervisors such as KVM, Xen, Hyper-V and ESXi run directly on the hardware; type 2 hypervisors such as VirtualBox, VMware Workstation and QEMU without acceleration run as an application on a host operating system.
Virtualization also explains the layers built on top of it. Live migration, high availability and dynamic scheduling exist because a running machine can be moved. Every IaaS cloud instance is a virtual machine on someone else's hypervisor. Containers are the sibling technology rather than the successor — they share one kernel and isolate with namespaces and cgroups instead of emulating hardware, which is why they start in milliseconds and why the isolation boundary is weaker. MicroVMs such as Firecracker and sandboxed runtimes such as Kata and gVisor sit deliberately between the two.
Virtualization stopped being a specialism and became the substrate. Every cloud instance, every Kubernetes node, every CI agent and most on-premises workloads run on a hypervisor, and the engineers operating them are expected to understand what that means when something is slow, oversubscribed or failing to migrate.
The practical demand has two shapes. On-premises estates still need people who can build, size, migrate and troubleshoot virtual infrastructure — and increasingly on KVM-based platforms rather than only on a single vendor, as organisations reassess licensing. In the cloud, the same knowledge shows up as instance family selection, noisy-neighbour diagnosis, nested virtualization for build agents, and understanding why a workload behaves differently on shared versus dedicated hardware.
The containers-versus-virtual-machines question also keeps arriving as a decision rather than a topic. Teams have to place workloads across virtual machines, containers and sandboxed runtimes based on isolation requirements, startup latency, density and operational cost. That decision needs someone who understands both mechanisms rather than someone who has only ever used one of them.
The mechanism before the products. Privilege rings and the trap-and-emulate model, why x86 was originally hard to virtualize, binary translation and paravirtualization as historical answers, and the type 1 versus type 2 distinction that decides where a hypervisor can be used.
Topics: Privilege levels and the trap-and-emulate model · Why classical x86 was not virtualizable · Binary translation and paravirtualization · Type 1 versus type 2 hypervisors · The hypervisor landscape: KVM, Xen, Hyper-V, ESXi, VirtualBox, QEMU · Full virtualization, paravirtualization and OS-level virtualization · Emulation versus virtualization — and when you actually need emulation
The two resources that decide density and performance. Hardware extensions and what they eliminate, vCPU scheduling and steal time, NUMA topology and why crossing a node hurts, then memory: second-level address translation, overcommit, ballooning, page sharing and huge pages.
Topics: Intel VT-x and AMD-V — what they actually accelerate · vCPU scheduling, co-scheduling and steal time · CPU pinning, topology and NUMA placement · CPU models, flags and migration compatibility · EPT and NPT second-level address translation · Memory overcommit, ballooning and swap behaviour under pressure · Page sharing, deduplication and huge pages · Sizing evidence: how many vCPUs a workload actually needs
The open-source stack most of the world's virtualization now runs on, including every major cloud. How KVM turns the Linux kernel into a hypervisor, what QEMU contributes, and how libvirt provides the management layer — with virsh, domain XML and virt-install as the working interface.
Topics: KVM as a kernel module and QEMU as the device model · libvirt architecture, virsh and the domain XML · Creating guests with virt-install and from templates · virtio drivers and paravirtualized devices · Guest lifecycle: define, start, pause, save, restore, undefine · Storage pools and volumes in libvirt · Cloud images and cloud-init for unattended provisioning · Xen and the other open-source hypervisors, briefly
The Microsoft side of the estate. Hyper-V architecture with its parent and child partitions, generation 1 versus generation 2 virtual machines, dynamic memory, integration services, and management through Hyper-V Manager, PowerShell and failover clustering.
Topics: Hyper-V architecture: hypervisor, parent partition, VMBus · Installing Hyper-V on Windows Server and on client Windows · Generation 1 and generation 2 virtual machines · Dynamic memory, startup memory and memory weight · Virtual switches: external, internal and private · Checkpoints, production checkpoints and their caveats · Managing Hyper-V with PowerShell · Failover clustering, live migration and cluster shared volumes
Where virtual disks actually live and what that costs. Image formats and their trade-offs, thin provisioning and its failure mode, copy-on-write snapshots and chain depth, backing stores from local disk to SAN and NFS, caching modes, and software-defined storage.
Topics: Image formats: raw, qcow2, VMDK, VHDX · Thick versus thin provisioning and running a datastore out of space · Copy-on-write snapshots, chain depth and consolidation · Backing stores: local, iSCSI, Fibre Channel, NFS · Multipathing and path failure behaviour · Caching modes and the durability implications of each · Software-defined storage: Ceph, vSAN and Storage Spaces Direct · Backup approaches for running virtual machines
Rebuilding the network in software. Linux bridges, tap devices and virtual switches, VLAN tagging and trunking, bonding and teaming for resilience, then the acceleration paths — virtio, vhost, SR-IOV and passthrough — and the overlay networks that make virtual topologies portable.
Topics: Linux bridges, tap devices and veth pairs · Virtual switches and distributed switching · VLAN tagging, trunk ports and port groups · NIC bonding, teaming and failover behaviour · virtio-net, vhost and the packet path cost · SR-IOV, virtual functions and PCI passthrough · Overlay networks: VXLAN, GENEVE and network virtualization platforms · Troubleshooting a guest that has a link but no connectivity
Running virtual infrastructure rather than building it. Live migration mechanics and what breaks it, high availability and its real guarantees, capacity planning and consolidation ratios, nested virtualization, device passthrough, and a systematic method for diagnosing a slow guest.
Topics: Live migration: pre-copy, post-copy and the memory dirty rate · Shared storage requirements and storage migration · CPU compatibility, masking and migration failures · High availability, fencing and split-brain · Capacity planning and consolidation ratios · Nested virtualization for labs and build agents · GPU and device passthrough with IOMMU · Performance triage: steal time, ballooning, I/O wait, interrupt overhead
The comparison every team eventually has to make. How namespaces and cgroups differ from hardware virtualization, what each isolation boundary actually resists, and the middle ground of microVMs and sandboxed runtimes — with a like-for-like measurement of the same workload in each.
Topics: Namespaces, cgroups and OS-level virtualization · What a shared kernel means for the isolation boundary · Startup latency, density and memory footprint compared · MicroVMs: Firecracker and Cloud Hypervisor · Sandboxed runtimes: Kata Containers and gVisor · Running containers on virtual machines, and why clouds do it · Multi-tenancy requirements and choosing accordingly · Placing real workloads across the three options
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a KVM host, define storage pools, provision guests from cloud images with cloud-init, and turn a hand-built guest into a reusable template.
Deliberately overcommit CPU and memory, measure steal time and ballooning pressure, then pin a latency-sensitive guest to a NUMA node and quantify the recovery.
Benchmark raw against qcow2, build a deep snapshot chain, measure the degradation and consolidate it — then run a datastore out of thin-provisioned space on purpose.
Trunk multiple VLANs to guests over a bonded interface, verify isolation, then attach an SR-IOV virtual function and measure the throughput and latency difference.
Migrate a heavily loaded guest between hosts, observe how the memory dirty rate determines convergence, then break migration with a CPU model mismatch and fix it.
Run one workload as a virtual machine, a container and a Firecracker microVM; measure startup, density, footprint and isolation, and write the placement standard.
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
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.
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.
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.